date:20091202

[Bug 490382] Re: eucalyptus-cc init script doesn't always clear /var/lib/eucalyptus/CC

2009-12-02 Thread Thierry Carrez

CLEAN=1 is supported in eucalyptus-cc.conf, not in eucalyptus.conf. So maybe 
it's something like:
stop eucalyptus CLEAN=1 - FAIL (env not passed to eucalyptus-cc)
stop eucalyptus-cc CLEAN=1 - PASS
start eucalyptus[-cc] CLEAN=1 - FAIL (start not supported, bug 491254)
restart eucalyptus CLEAN=1 - FAIL (env not passed to eucalyptus-cc)

Looks quite non-deterministic from here.
Dustin, if you can confirm the above behavior, in the end it's a matter of what 
CLEAN commands we want to support. IMHO we should support restart eucalyptus 
CLEAN=1 and stop eucalyptus CLEAN=1, start eucalyptus CLEAN=1, stop 
eucalyptus-cc CLEAN=1 and start eucalyptus[-cc] CLEAN=1, since we mainly use 
the eucalyptus script to drive eucalyptus in general, but should also support 
stopping and starting eucalyptus-cc only.

-- 
eucalyptus-cc init script doesn't always clear /var/lib/eucalyptus/CC
https://bugs.launchpad.net/bugs/490382
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 461156] Re: User data is not parsed correctly by Eucalyptus in some cases

2009-12-02 Thread Thierry Carrez

** Description changed:

- User data supplied using euca-run-instances --user-data-file is not decoded 
before being presented to the instance. 
- Inside the instance, curl http://169.254.169.254/latest/user-data; should 
fetch the decoded user data, whereas eucalyptus will return a base64 and url 
encoded string. This breaks ec2-run-user-data from the ec2-init package, 
rendering instance configuration using the user-data mechanism unusable. 
+ User data supplied using euca-run-instances --user-data-file is not decoded 
before being presented to the instance.
+ Inside the instance, curl http://169.254.169.254/latest/user-data; should 
fetch the decoded user data, whereas eucalyptus will return a base64 and url 
encoded string. This breaks ec2-run-user-data from the ec2-init package, 
rendering instance configuration using the user-data mechanism unusable.
  
  EC2 documentation at 
http://docs.amazonwebservices.com/AWSEC2/2007-03-01/DeveloperGuide/AESDG-chapter-instancedata.html
 states that EC2 will return decoded data (i don't have a ec2 account so i 
can't confirm this):
  The user data must be base64-encoded before being submitted to the API. The 
API command-line tools perform the base64-encoding for you. The data will be 
base64 decoded before being presented to the instance.
+ 
+ =
+ SRU Report (eucalyptus, euca2ools):
+ 
+ Impact: This bug makes userdata unusable in cloud images used withing
+ UEC. userdata is used for a lot of things, in particular boot-time
+ configuration of our cloud images. This works within EC2 but not within
+ UEC, due to this bug.
+ 
+ This requires a fix in euca2ools (do not b64_encode twice). But fixing
+ it in euca2ools triggers a bug in eucalyptus when certain userdata is
+ received (the previous bug was protecting eucalyptus from this), so this
+ needs a eucalyptus update as well.
+ 
+ Fix in development release: This was fixed in lucid in eucalyptus
+ (1.6.1~bzr1083-0ubuntu1) by applying the same patch. Was not fixed in
+ euca2ools yet.
+ 
+ Minimal patch for eucalyptus:
+ 
http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu-karmic/revision/726
+ 
+ Minimal patch for euca2ools:
+ --- euca2ools-1.0+bzr20091007.orig/bin/euca-run-instances
+ +++ euca2ools-1.0+bzr20091007/bin/euca-run-instances
+ @@ -170,8 +170,6 @@
+   print 'Invalid user data file path'
+   sys.exit(1)
+   user_data = read_user_data(user_data_file)
+ - if user_data:
+ - user_data = base64.urlsafe_b64encode(user_data)
+  euca_conn = euca.make_connection()
+   try:
+  reservation = euca_conn.run_instances(image_id = image_id,
+ 
+ TEST CASE:
+ euca-run-instances -k $MYKEY --user-data   FOO  $EMI -t c1.medium
+ ssh -i $MYKEYPRIV ubu...@$ip 'wget -q http://169.254.169.254/latest/user-data 
-O -'; echo
+ Expected results: should return   FOO 
+ Fails with affected euca2ools and eucalyptus (returns IDw8IEZPTyA- instead 
of   FOO )
+ Succeeds with proposed euca2ools and proposed eucalyptus.
+ 
+ Regression potential:
+ The regression potential is small, since userdata is not really usable right 
now. In euca2ools, only someone relying on the bug (and base64_decoding the 
userdata in the cloud image itself) would be affected. Regression potential is 
slightly higher on eucalyptus side, since the fix is about escaping special 
characters in userdata. Careful testing with various userdata strings (to hit 
the special characters in the urlsafe-base64-encoded string) is necessary.
  
  =
  Karmic release notes:
  
  user-data not usable by guest instances
  
  Starting an instance with euca-run-instances and user-data (either using
  the -d, --user-data option or the -f, --user-data-file option) will
  store the user data  in base64 encoding. Accessing the user data from
  the instance at http://169.254.169.254/latest/user-data will return the
  user data in base64 encoding. Because of this bug ec2-init is unable
  make use of user-data. In order to use this data it must first be
  decoded. A fix for this issue is expected to be provided in a post-
  release update immediately after the Ubuntu 9.10 release.
  
  ==

-- 
User data is not parsed correctly by Eucalyptus in some cases
https://bugs.launchpad.net/bugs/461156
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 491273] [NEW] netfs storage pools are not autostarted at boot (karmic)

2009-12-02 Thread Alvin

Public bug reported:

Release: ubuntu 9.10
libvirt-bin: 0.7.0-1ubuntu13.1

libvirt mounts defined 'netfs' storage pools when the libvirt service is
started. When started at boot time, this does not happen. Restarting
libvirt-bin after boot mounts the drives.

Virtual machines on NFS storage pools can not be autostarted.

** Affects: libvirt (Ubuntu)
 Importance: Undecided
 Status: New

-- 
netfs storage pools are not autostarted at boot (karmic)
https://bugs.launchpad.net/bugs/491273
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 461156] Re: User data is not parsed correctly by Eucalyptus in some cases

2009-12-02 Thread Thierry Carrez

** Description changed:

User data supplied using euca-run-instances --user-data-file is not decoded
before being presented to the instance.
Inside the instance, curl http://169.254.169.254/latest/user-data; should
fetch the decoded user data, whereas eucalyptus will return a base64 and url
encoded string. This breaks ec2-run-user-data from the ec2-init package,
rendering instance configuration using the user-data mechanism unusable.

EC2 documentation at
http://docs.amazonwebservices.com/AWSEC2/2007-03-01/DeveloperGuide/AESDG-chapter-instancedata.html
states that EC2 will return decoded data (i don't have a ec2 account so i
can't confirm this):
The user data must be base64-encoded before being submitted to the API. The
API command-line tools perform the base64-encoding for you. The data will be
base64 decoded before being presented to the instance.

=
SRU Report (eucalyptus, euca2ools):

Impact: This bug makes userdata unusable in cloud images used withing
UEC. userdata is used for a lot of things, in particular boot-time
configuration of our cloud images. This works within EC2 but not within
UEC, due to this bug.

This requires a fix in euca2ools (do not b64_encode twice). But fixing
it in euca2ools triggers a bug in eucalyptus when certain userdata is
received (the previous bug was protecting eucalyptus from this), so this
needs a eucalyptus update as well.

Fix in development release: This was fixed in lucid in eucalyptus
- (1.6.1~bzr1083-0ubuntu1) by applying the same patch. Was not fixed in
- euca2ools yet.
+ (1.6.1~bzr1083-0ubuntu1) and in euca2ools (1.0+bzr20091007-0ubuntu2) by
+ applying the same patches.

Minimal patch for eucalyptus:

http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu-karmic/revision/726

Minimal patch for euca2ools:
--- euca2ools-1.0+bzr20091007.orig/bin/euca-run-instances
+++ euca2ools-1.0+bzr20091007/bin/euca-run-instances
@@ -170,8 +170,6 @@
- print 'Invalid user data file path'
- sys.exit(1)
- user_data = read_user_data(user_data_file)
+ print 'Invalid user data file path'
+ sys.exit(1)
+ user_data = read_user_data(user_data_file)
- if user_data:
- user_data = base64.urlsafe_b64encode(user_data)
- euca_conn = euca.make_connection()
- try:
- reservation = euca_conn.run_instances(image_id = image_id,
+ euca_conn = euca.make_connection()
+ try:
+ reservation = euca_conn.run_instances(image_id = image_id,

TEST CASE:
euca-run-instances -k $MYKEY --user-data FOO $EMI -t c1.medium
ssh -i $MYKEYPRIV ubu...@$ip 'wget -q http://169.254.169.254/latest/user-data
-O -'; echo
Expected results: should return FOO
Fails with affected euca2ools and eucalyptus (returns IDw8IEZPTyA- instead
of FOO )
Succeeds with proposed euca2ools and proposed eucalyptus.

Regression potential:
The regression potential is small, since userdata is not really usable right
now. In euca2ools, only someone relying on the bug (and base64_decoding the
userdata in the cloud image itself) would be affected. Regression potential is
slightly higher on eucalyptus side, since the fix is about escaping special
characters in userdata. Careful testing with various userdata strings (to hit
the special characters in the urlsafe-base64-encoded string) is necessary.

=
Karmic release notes:

user-data not usable by guest instances

Starting an instance with euca-run-instances and user-data (either using
the -d, --user-data option or the -f, --user-data-file option) will
store the user data in base64 encoding. Accessing the user data from
the instance at http://169.254.169.254/latest/user-data will return the
user data in base64 encoding. Because of this bug ec2-init is unable
make use of user-data. In order to use this data it must first be
decoded. A fix for this issue is expected to be provided in a post-
release update immediately after the Ubuntu 9.10 release.

** Changed in: euca2ools (Ubuntu)
Assignee: Scott Moser (smoser) = Thierry Carrez (ttx)

--
User data is not parsed correctly by Eucalyptus in some cases
https://bugs.launchpad.net/bugs/461156
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to eucalyptus in ubuntu.

--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

75 matches

Mail list logo