On 09/24/10 - 01:45:42AM, Scott Seago wrote: > I've updated condormatic.rb to iterate over the new > template/image/replicated_image model. > > Signed-off-by: Scott Seago <[email protected]> > --- > src/app/util/condormatic.rb | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/app/util/condormatic.rb b/src/app/util/condormatic.rb > index a38c369..e051c24 100644 > --- a/src/app/util/condormatic.rb > +++ b/src/app/util/condormatic.rb > @@ -49,7 +49,7 @@ def condormatic_instance_create(task) > pipe.puts resource > Rails.logger.info resource > > - requirements = "requirements = hardwareprofile == > \"#{instance.hardware_profile.id}\" && image == \"#{instance.image.id}\"" > + requirements = "requirements = hardwareprofile == > \"#{instance.hardware_profile.id}\" && image == \"#{instance.template.id}\""
OK, after going through this with Scott, this seems to make sense. On the UI the user ends up picking a template. The template is mapped to an image, which is then matched to replicated_image once it is on a particular cloud. So what we do is advertise to condor the template.id that we are looking for, and then match that on the template.id that the user picked. If we match those, then we substitute in the replicated_image name that we have in the database, which is what we need to actually start the job in condor. This makes sense. ACK -- Chris Lalancette _______________________________________________ deltacloud-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/deltacloud-devel
