Thanks for the update. I've donwloaded the latest development version
This is what I got when I invoked "starcluster start smallcluster
test" (there is a cluster template "smallcluster" defined in the
cluster.py:525 - ERROR - The AVAILABILITY_ZONE = %s is not available
at this time
Traceback (most recent call last):
File "/usr/local/bin/starcluster", line 5, in <module>
line 442, in run_script
line 1167, in run_script
exec script_code in namespace, namespace
line 6, in <module>
line 585, in main
line 184, in execute
line 478, in is_valid
line 616, in _validate_ebs_settings
TypeError: 'NoneType' object is not iterable
On Mon, Mar 29, 2010 at 8:55 AM, Justin Riley <jtriley_at_mit.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi Nicholas,
> Awesome, I'll try to wget that url on a local instance sometime today
> and see how it goes just to verify that this is the case (ie latest
> points to 1.0 by default on 1.6.2)
> I meant to send you an announcement this last night, but I made some
> modifications that should allow you to get past the credentials step
> when starting StarCluster on Eucalyptus. You'll need to pull in the
> latest code to test it out.
> Please let me know how things go and what the next obstacles are.
> I am aware of one obstacle that guarantees things will not quite run
> successfully. When we do:
> $ starcluster listinstances
> I noticed that both of our outputs of this command using Eucalyptus
> reports private_ip_address and ip_address as N/A. These variables are
> used by StarCluster to setup things like /etc/hosts, Sun Grid Engine, etc.
> I have a feeling this is due to needing a more sophisticated DNS setup
> with Eucalyptus but I haven't tried to solve this just yet. In any
> event, things will almost certainly not work until we can get these
> values to be properly populated (ie starcluster listinstances should
> show the ip addresses and not N/A's).
> Hope that helps,
> On 03/29/2010 11:06 AM, Nicholas Ampazis wrote:
>> I do have a "add_key.pl" in the "/usr/share/eucalyptus" directory.
>> However this might not be much relevant in the process of copying the
>> ssh key in later versions of Eucalyptus (i.e. 1.6.x), since I've
>> discovered that I could have achieved the same fix if I had
>> (instead of public_key_url=http://169.254.169.254/2008-02-01/meta-data/public-keys/0/openssh-key)
>> in /etc/init.d/ec2-get-credentials" of starcluster iso.
>> Notice that in this case "latest" points to the same directory as
>> "api_ver" which in your eucalyptus installation (1.6.2) just happens
>> to be "1.0", so it works out of the box!
>> P.S. Is there any progress in the starcluster git python code with
>> regards to commands that did not work with eucalyptus credentials
>> (e.g. starcluster start , etc)?
>> On Mon, Mar 29, 2010 at 7:35 AM, Justin Riley <jtriley_at_mit.edu> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> Hi Nicholas,
>>> Awesome, glad to hear you've got the StarCluster ami working with
>>> Eucalyptus. I'm still a little curious as to why I didn't need those
>>> modifications to /etc/init.d/ec2-get-credentials and you did.
>>> My current theory on this:
>>> I believe that Eucalyptus is running the script
>>> $EUCALYPTUS/usr/share/eucalyptus/add_key.pl somewhere in the process of
>>> bringing the instance up.
>>> Looking at this script it appears that they manually pipe the pub key
>>> into root's authorized_keys file (ie they're mounting the iso and
>>> creating the authorized_keys outside of the instance).
>>> My only guess as to why my EMI worked out of the box with respect to ssh
>>> is because of this script. Maybe it's not being executed for some reason?
>>> Can you check if that script exists for you in /usr/share/eucalyptus?
>>> Thanks and in any event, thanks for tracking this down :D
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> -----END PGP SIGNATURE-----
Received on Mon Mar 29 2010 - 12:09:20 EDT