dutils
by Simon Harris
I notice a few files in dutils for establishing a Rails environment.
If we made any scripts we wanted to run rake tasks, we'd simply need to depend on the :environment task.
Failing that, we could always do
rails runner "some script"
In any event, all that is really needed to load the environment is:
require File.expand_path('some_relative_path_to/config/environment', __FILE__)
Anything I missed that means we need those other two files?
Simon
12 years, 8 months
Rails3 and fedora-14 support
by steve linabery
While the Fedora 15 testing repos [1] have been functional for some time now, building packages for Fedora 14 has hit an impasse. In particular, rubygem-activerecord-3.0.9-1.fc16.src.rpm does not build for f14. I've posted the build log from mock [2], just in case any aeolus developers can see an obvious workaround.
With the scheduled release of Fedora 16 rapidly approaching, my inclination is to spend no more time trying to support development on Fedora 14. However, I can't unilaterally decide that Fedora 14 support is unimportant to the aeolus project community. Does anyone strongly object to restricting development support to >= Fedora 15?
TIA for your input,
Steve|eggs
[1] http://repos.fedorapeople.org/repos/aeolus/conductor/testing/fedora-15/
[2] http://slinabery.fedorapeople.org/build.log
12 years, 8 months
(no subject)
by Scott Seago
A future enhancement might be to make it easier to enter this new param, depending on the type -- for ec2 we'll have a hard-coded picklist (us-east-1, etc), for RHEV/VMWare, etc some sort of helper to get the format right, etc.
I also added a settings.yml file with a default value for provider URL set to http://localhost:3002/api, and the provider form pre-fills this on 'new'.
This should be backwards-compatible with the one-core-per-provider scheme that -configure currently sets up, but we should probably do the following in configure once this patchset is pushed:
1) configure should ensure that settings.yml has the same provider URL as it configures
2) custom deltacloud-core services go away
3) the standard "deltacloud-core" service that we're disabling now should be enabled
4) the providers created by configure need to have deltacloud_provider set on the creation form to match what we used to use as the default endpoint in the separate core services, and all pointing to the same default URL
In testing this, we need to make sure that everything works with the current default providers created by configure in addition to testing multiple providers via the deltacloud_provider field.
From: Scott Seago <sseago(a)redhat.com>
Subject: [Conductor PATCH 0/7] Enable shared deltacloud-core instances for multiple providers
In-Reply-To:
12 years, 8 months
[PATCH conductor] Add javascript paths to port 80 virtualhost.
by Jason Guiditta
We have this already in the ssl version, but should have
it here too.
---
conf/aeolus-conductor-httpd.conf | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/conf/aeolus-conductor-httpd.conf b/conf/aeolus-conductor-httpd.conf
index 2b211b2..c4e6a77 100644
--- a/conf/aeolus-conductor-httpd.conf
+++ b/conf/aeolus-conductor-httpd.conf
@@ -10,14 +10,18 @@ NameVirtualHost *:80
Alias /conductor/stylesheets "/usr/share/aeolus-conductor/public/stylesheets"
Alias /conductor/images "/usr/share/aeolus-conductor/public/images"
Alias /conductor/errors "/usr/share/aeolus-conductor/public/"
+Alias /conductor/javascripts "/usr/share/aeolus-conductor/public/javascripts"
+Alias /fonts "/usr/share/aeolus-conductor/public/fonts"
ProxyPass /conductor/images !
ProxyPass /conductor/stylesheets !
ProxyPass /conductor/errors !
+ProxyPass /conductor/javascripts !
ProxyPass /conductor http://localhost:3000/conductor
ProxyPassReverse /conductor http://localhost:3000/conductor
ProxyPassReverse /conductor/images !
ProxyPassReverse /conductor/stylesheets !
ProxyPassReverse /conductor/errors !
+ProxyPassReverse /conductor/javascripts !
</VirtualHost>
--
1.7.4.4
12 years, 8 months
[PATCH conductor] Fixed users factory
by Jan Provazník
From: Jan Provaznik <jprovazn(a)redhat.com>
this change made all my tests failing (probably depends on version
of some gem), reverting this back:
- after_build { |u| u.email ||= "#{u.login}(a)example.com" }
+ u.email { |e| "#{e.login}(a)example.host" }
---
src/spec/factories/user.rb | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/spec/factories/user.rb b/src/spec/factories/user.rb
index 44eb581..8c222c0 100644
--- a/src/spec/factories/user.rb
+++ b/src/spec/factories/user.rb
@@ -7,7 +7,7 @@ FactoryGirl.define do
first_name 'John'
last_name 'Smith'
association :quota
- u.email { |e| "#{e.login}(a)example.host" }
+ after_build { |u| u.email ||= "#{u.login}(a)example.com" }
end
factory :other_named_user, :parent => :user do
--
1.7.6
12 years, 8 months
[PATCH conductor] Disable Backbone fallback to hash-based URLs
by Tomas Sedovic
From: Tomas Sedovic <tsedovic(a)redhat.com>
In browsers that don't support the HTML5 History API, Backbone redirects URLs
to the hash-based format.
E.g. /deployments/1 becomes /#deployments/1
This behaviour breaks the app, because Rails render the page located at the
root path.
Since we don't use the Backbone's capabilities that require this behaviour, we
disable it for the time being.
If we want to use them later, a modification of Rails routing logic will be
required.
---
src/app/views/layouts/application.haml | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/app/views/layouts/application.haml b/src/app/views/layouts/application.haml
index 7fa81e7..e7a8ced 100644
--- a/src/app/views/layouts/application.haml
+++ b/src/app/views/layouts/application.haml
@@ -13,14 +13,20 @@
= stylesheet_link_tag '/stylesheets/layout_ie.css'
= stylesheet_link_tag '/stylesheets/compiled/custom.css'
+ :javascript
+ window.Conductor = {}
+ window.Conductor.PATH_PREFIX = "#{root_path}"
+ // This hack prevents Backbone from switching to the #/pools/1 type URLs
+ // when the browser doesn't support the HTML5 History API.
+ window.history || (window.history = {});
+ window.history.pushState || (window.history.pushState = function(){});
+
= javascript_include_tag "jquery-1.6.1.min.js"
= javascript_include_tag "jquery.ui-1.8.1/jquery-ui-1.8.1.custom.min.js"
= javascript_include_tag "jquery.tmpl.min.js"
= javascript_include_tag "underscore-min.js"
= javascript_include_tag "backbone-min.js"
- :javascript
- window.Conductor = {}
- window.Conductor.PATH_PREFIX = "#{root_path}"
+
= javascript_include_tag "application.js"
= javascript_include_tag "yetii-min.js"
--
1.7.6
12 years, 8 months
[PATCH conductor] Disable Backbone fallback to hash-based URLs
by Tomas Sedovic
From: Tomas Sedovic <tsedovic(a)redhat.com>
In browsers that don't support the HTML5 History API, Backbone redirects URLs
to the hash-based format.
E.g. /deployments/1 becomes /#deployments/1
This behaviour breaks the app, because Rails render the page located at the
root path.
Since we don't use the Backbone's capabilities that require this behaviour, we
disable it for the time being.
If we want to use them later, a modification of Rails routing logic will be
required.
---
src/app/views/layouts/application.haml | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/app/views/layouts/application.haml b/src/app/views/layouts/application.haml
index 7fa81e7..b99a45a 100644
--- a/src/app/views/layouts/application.haml
+++ b/src/app/views/layouts/application.haml
@@ -13,14 +13,20 @@
= stylesheet_link_tag '/stylesheets/layout_ie.css'
= stylesheet_link_tag '/stylesheets/compiled/custom.css'
+ :javascript
+ window.Conductor = {}
+ window.Conductor.PATH_PREFIX = "#{root_path}"
+ // This hack prevents Backbone from switching to the #/pools/1 type URLs
+ // when the browser doesn't support the HTML5 History API.
+ window.history = window.history || {};
+ window.history.pushState = window.history.pushState || function(){};
+
= javascript_include_tag "jquery-1.6.1.min.js"
= javascript_include_tag "jquery.ui-1.8.1/jquery-ui-1.8.1.custom.min.js"
= javascript_include_tag "jquery.tmpl.min.js"
= javascript_include_tag "underscore-min.js"
= javascript_include_tag "backbone-min.js"
- :javascript
- window.Conductor = {}
- window.Conductor.PATH_PREFIX = "#{root_path}"
+
= javascript_include_tag "application.js"
= javascript_include_tag "yetii-min.js"
--
1.7.6
12 years, 8 months
[Feature conductor] Define useful uptime(s)
by jzigmund＠redhat.com
Hi Conductor developers,
I'm working on task from Redmine
(https://www.aeolusproject.org/redmine/issues/1965). I'm sending some
suggestion how to make reporting of uptime until we won't use Matahari project
for this purpose.
What we want:
* The total amount of time that at least one instance in a deployable was
running
* The amount of time that all instances were running, and the deployable was
therefore complete
Suggestion:
Now we store information about various types of time for instance (like
time_last_running) and also accumulative times for it in DB.
We could add new events for deployment what will indicate a state:
* 1st_running - when 1st of all instance will run
* all_running - when all instances of deployment will run
This events will be created in the instance_observer.rb. After then we could
count required times with help of these events. Also we will fix case when one
of instances fail, then we should stop counting 'The amount of time that all
instances were running'.
Please if someone will have other idea how to do it in other way, reply to
this e-mail.
--
Jozef Zigmund
12 years, 8 months
The Image Factory interface
by Ian McLeod
All,
I'm writing this to summarize a lengthy IRC and phone discussion from
earlier today that included Hugh, Steve, Chris, Jay and me (among
others). If anyone who was involved thinks I'm mis-representing
anything, please chime in.
(Note that I am intentionally discussing only the question of the
interface here, not the separate and largely orthogonal issue of status
updates and logging.)
So, as things currently stand, the process of building and pushing
images occurs outside of conductor in the "aeolus-image" command line
tool. This tool uses the existing QMF interface to the factory to drive
the build and push process.
There is a desire to move building and pushing back into the Conductor
web app.
As far as we know, it is still not possible to cleanly integrate the QMF
Ruby console bindings into the rails app itself. Jay encountered a
number of issues when originally attempting to do this. The two most
significant were excessive blocking of the entire rails process and the
need to restart the web app to recover from a failure or restart of the
qpid broker. We believe these issues still exist.
We discussed a range of options to address this:
1) Have the webapp call the aeolus-image CLI directly and just parse the
results - This is a quick hack but is probably workable.
2) Push to resolve the QMF Ruby binding issues to make it possible for
the webapp to run as a console - We've no idea of the scope of effort
required to do this.
3) Add a REST-style API to the Factory - This appeals as REST is already
widely used by other Aeolus project components (DC core api, iwhd,
numerous external and private cloud providers, Conductor itself, etc.).
It would also remove our dependency on the qpid components entirely. We
saw no particular technical issues that would stop us from doing this.
The structure of the Factory code makes it relatively easy to add a new
front-end interface.
We've tentatively added this to Redmine as issue 2142 though we have not
committed to it or included it in a particular sprint yet.
Thoughts?
-Ian
12 years, 8 months
