On 06/21/2011 02:25 PM, Chris Lalancette wrote:
On 06/21/11 - 10:58:45AM, Jan Provaznik wrote:
> As condor matching process (when starting an instance) was moved to
> conductor we can simplify instance SSH key generation for EC2 accounts.
> SSH keys are always associated with an EC2 account. A user generates SSH
> key pair for the account and gets back ID for this key pair. Then when
> the user starts an instance he passes ID of the key pair generated before.
>
> With matching in condor we didn't know where an instance will be started
> (which provider/provider account will condor choose) so we didn't know
> for which provider account new unique key pair should be generated. So
> we had to use a default key for starting the instance and replace the
> default key with new unique key when instance was started.
>
> Now as matching is done on conductor side we know which provider account
> will be used so we can simply generate unique SSH key pair for the new
> instance before before a launch request is passed to condor. Then we can
> remove instance observer and delayed_job and ssh key replacement logic.
> This change is quite simple, should we do this in this sprint?
That's not a bad idea at all, and I would love to get rid of some more
components. I don't see why not :)
>
> And one more question: all what condor does is running async deltacloud
> API requests. Any reason why not replace whole condor with some other
> more ruby friendly solution? There is a bunch of nice projects for
> running async tasks in ruby.
While I agree with you to some extent, condor does do more than that. It also
monitors the jobs for health. And while we could replace it, we do have a
bunch invested in it, and I don't see a compelling reason to remove it at the
moment. Ruby-friendly is not a reason :).
Not sure what exactly means jobs monitoring for health. Does it mean for
example requests failure checking or checking the status of running
instances or something else?
"ruby-friendly replacement" means:
- we can drop dependency on our own condor rpms
- no need to modify cpp source code and rebuild condor anytime we want
to update communication with deltacloud API (for example add a new
parameter)
- no need to have additional scripts for processing condor input/output
- with proper ruby tool code could be much more simpler so it probably
means also less bugs related to this part of aeolus
Jan