On 07/28/2011 09:19 AM, Chris Lalancette wrote:
On 07/27/11 - 04:56:14PM, mtaylor(a)redhat.com wrote:
> From: Martyn Taylor <mtaylor(a)redhat.com>
>
> ---
> src/app/util/condormatic.rb | 2 ++
> src/config/condor.yml | 1 +
> 2 files changed, 3 insertions(+), 0 deletions(-)
> create mode 100644 src/config/condor.yml
>
> diff --git a/src/app/util/condormatic.rb b/src/app/util/condormatic.rb
> index b52ff46..45aa4bd 100644
> --- a/src/app/util/condormatic.rb
> +++ b/src/app/util/condormatic.rb
> @@ -29,6 +29,7 @@ class Possible
> @hwp = hwp
> @provider_image = provider_image
> @realm = realm
> + @condor_config = YAML.load_file("#{RAILS_ROOT}/config/condor.yml")
> end
> end
>
> @@ -93,6 +94,7 @@ def condormatic_instance_create(task)
> pipe_and_log(pipe, "DeltacloudUsername =
#{found.account.credentials_hash['username']}\n")
> pipe_and_log(pipe, "DeltacloudPasswordFile = #{pwfilename}")
> pipe_and_log(pipe, "DeltacloudImageId =
#{found.provider_image.target_identifier}\n")
> + pipe_and_log(pipe, "DeltacloudRetryTimeout =
#{@condor_config[:request_timeout]}\n")
> pipe_and_log(pipe,
> "DeltacloudHardwareProfile =
#{found.hwp.external_key}\n")
> pipe_and_log(pipe,
Hm, I'm not sure I love these kinds of patches. In particular, I want us to
start getting away from using configuration files, because the administrator
has no idea on how to set them and they are not dynamic enough. For instance,
in this case, what value would you want the administrator to set? In what
circumstances would he change it? If you add a new cloud provider type, is
the timeout correct?
In this case, I think we can do a lot better by modifying the timeout
ourselves. That is, by this point of the code, we know which provider backend
we are going to be using. So we should use that information and do a table
lookup.
EC2? -> default timeout
VMware -> 180 seconds
RHEV -> 90 seconds
etc.
(note that I just made the above numbers up, they can be whatever we need to
be correct)
Hi Chris,
I think you have a fair point. Although I was specifically tasked with
making this value configurable.
How about I put a table like you described above in the config file?
This allows us to gives the best of both worlds.
I understand what you are saying with regards to configuration being
complex, though I think an administrator would/should have enough
information to make a decision on these types of things. Maybe that
means we need documentation to go along side the configuration. Say my
VMWare server, is really Slow, I might need to tinker with some of the
values.
I do think we could do with an amalgamation of the many files we have
under config folder and we need to document the resulting file
appropriately.