[PATCH conductor] travis-ci.org configuration file for upstream continous integration testing
by Richard Su
Runs cucumber and rspec within a single build. Uses bundler.
Runs build for ruby 1.8.7 and 1.9.3.
Notifies freenode #aeolus when build is done.
---
.travis.yml | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
create mode 100644 .travis.yml
diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0000000..d2cdb85
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,30 @@
+language: ruby
+rvm:
+ - 1.8.7
+ - 1.9.3
+gemfile: src/Gemfile
+env:
+ - SUITE=cucumber
+ - SUITE=spec
+before_install:
+ - sed s/'pg'/'sqlite3'/ src/Gemfile.in > src/Gemfile
+install:
+ - cd src
+ - bundle install
+before_script:
+ - export USE_BUNDLER=yes
+ - cp config/database.sqlite config/database.yml
+ - rake dc:oauth_keys
+ - rake db:drop
+ - rake db:create
+ - rake db:migrate
+ - rake db:seed
+ - rake db:test:prepare
+script:
+ - rake $SUITE
+notifications:
+ irc:
+ channels:
+ - "irc.freenode.org#aeolus"
+ use_notice: true
+ skip_join: false
\ No newline at end of file
--
1.7.7.6
11 years, 9 months
Katello-Foreman-Aeolus Integration
by Chris Alfonso
There has been a bit of discussion going on around how we might go about using foreman's ability to do host provisioning with aeolus and katello. I've published some of the notes from the discussions here:
http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integr...
http://etherpad-aeolusproject.rhcloud.com/p/Katello-Foreman-Aeolus-Integr...
The suggested end goal of this integration is:
1) Allow Katello to clone content, create a snapshot of the content (Content View).
2) Generate the data needed for an Oz template and store it with the Foreman HostGroups.
3) Allow Aeolus to provision guests *and* be able to use the Foreman capabilities around post-boot configuration.
If there are additional goals to this integration that I've overlooked and you know about them, please respond with your intel. Take a look at the use cases, and feel free to annotate or reply to this thread.
- Chris
11 years, 9 months
[PATCH conductor 0/11] RM3392, 3394, converge-ui, login layout rev1
by Jirka Tomasek
RM3392, RM3394 This patchset updates the converge-ui used by Conductor
to latest commit, brings new stylesheets, images, javascript libs from
it. Patchset also makes Conductor to use converge-ui Login layout.
git-send-email won't allow me to send the patchset so I added the
patches as attachment.
(rev1: added one more patch to the patchset)
Jirka
11 years, 9 months
[PATCH aeolus-configure] BZ835131 configure errors after upgrade
by steve linabery
Change the behavior of site_admin.pp to rely on a db check
(via 'rake dc:admin_exists' task) instead of a filesystem check.
---
recipes/aeolus/manifests/conductor/site_admin.pp | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/recipes/aeolus/manifests/conductor/site_admin.pp b/recipes/aeolus/manifests/conductor/site_admin.pp
index 4c3a91d..4f90fca 100644
--- a/recipes/aeolus/manifests/conductor/site_admin.pp
+++ b/recipes/aeolus/manifests/conductor/site_admin.pp
@@ -5,17 +5,12 @@ define aeolus::conductor::site_admin($email="", $password="", $first_name="", $l
environment => "RAILS_ENV=production",
command => "/usr/bin/rake dc:create_user[${name},${password},${email},${first_name},${last_name}]",
logoutput => true,
- creates => "/var/lib/aeolus-conductor/production.admin",
+ unless => '/usr/bin/rake dc:admin_exists',
require => Aeolus::Rails::Seed::Db["seed_aeolus_database"]}
exec{"grant_site_admin_privs":
cwd => '/usr/share/aeolus-conductor',
environment => "RAILS_ENV=production",
command => "/usr/bin/rake dc:site_admin[${name}]",
logoutput => true,
- creates => "/var/lib/aeolus-conductor/production.admin",
require => Exec[create_site_admin_user]}
- file{"/var/lib/aeolus-conductor/production.admin":
- ensure => present,
- recurse => true,
- require => Exec['grant_site_admin_privs']}
}
--
1.7.6.5
11 years, 9 months
[PATCH conductor] BZ835131 configure errors after upgrade
by steve linabery
Add dc:admin_exists task
We need to query via ActiveRecord to see if a user with
admin privileges already exists. This allows us to replace
the behaviour in aeolus-configure that creates (and checks for)
a file to determine whether an admin has been created. Instead
we will look for an existing type of privilege.
---
src/lib/tasks/dc_tasks.rake | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/src/lib/tasks/dc_tasks.rake b/src/lib/tasks/dc_tasks.rake
index b3581c0..5993cd4 100644
--- a/src/lib/tasks/dc_tasks.rake
+++ b/src/lib/tasks/dc_tasks.rake
@@ -180,6 +180,13 @@ namespace :dc do
end
end
+ task :admin_exists => :environment do
+ no_admins = BasePermissionObject.general_permission_scope.permissions.includes(:role => :privileges).where("privileges.target_type" => "BasePermissionObject","privileges.action" => Privilege::PERM_SET).empty?
+ if no_admins
+ exit(1)
+ end
+ end
+
def get_account(provider_name, account_name)
unless provider = Provider.find_by_name(provider_name)
raise "There is no provider with '#{provider_name}' name"
--
1.7.6.5
11 years, 9 months
Data safety for our Fedora releases... :)
by Justin Clift
Hi all,
The good news (first)
*!*!*!*!*!*!*
We have working Aeolus rpm's are in official Fedora channels. (it's
been like this for a while) :)
The Challenge
*!*!*!*!*!*!*
How do we nicely update user data between Aeolus releases, without
losing anything or causing downtime?
For example, we have Aeolus 0.10.2 in Fedora 16.
When a new Aeolus version comes out (0.11.x, 0.12.x, 0.13.x, ...),
if it needs an upgraded the database schema, we can't let it break
existing installations.
As a first thought, this kind of presents two potential approaches:
a) If a new Aeolus version needs a db change, let's not push that
new Aeolus version to the Fedora official repos.
Example, Fedora 16 wouldn't get 0.11.0 (if 0.11.0 requires
db changes - no idea, it's just an example). :)
This doesn't stop us from pushing 0.11.0 to a new Fedora release
which has never had 0.10.2. (or rawhide, who's purpose is testing
new stuff)
b) We figure out some way of upgrading the database automatically.
So, Aeolus 0.10.2 in F16 example again. SysAdmin does "yum update",
maybe gets a new kernel at the same time... system reboots... and
Aeolus 0.11.0 is installed, running fine, and has automatically
updated the db as needed in the background. (no SysAdmin
intervention required).
There might be other approaches, but the two above stood out as most
obvious. a) sounds like the easiest, but it's probably not the
right move. Several months down the track from now, being stuck with
"ancient" versions of Aeolus releases in Fedora is unlikely to work for
us.
Piwik (for example) can do in place database upgrades, performed by the
running app itself. It's not going to be the only one whose approach
we could copy from... ;)
Does anyone have experience with this kind of thing with other db backed
web apps?
Regards and best wishes,
Justin Clift
--
Aeolus Community Manager
http://www.aeolusproject.org
11 years, 9 months
[ANNOUNCE] Deltacloud API 1.0 release notes
by Michal Fojtik
Hi guys,
On 19 June we announced a new milestone version of Deltacloud API, 1.0.0.
This version came with a **huge** list of improvements[1].
This is a quick wrap-up of the most important additions:
* Deltacloud API now comes with Amazon EC2 API front end. This should help
customers who already have EC2-based infrastructure to easily switch between
providers without reworking their codebase. This front end is experimental and
just few limited features are supported, like launching an instance, querying
images/instances and managing instance state. Ability to run multiple frontends
(deltacloudd -f ec2, cimi, deltacloud)
* Deltacloud is now a modular[2] Sinatra application and can be used as an
extension for any Rack-based application by mounting. As a side effect, we now
expose our drivers API as a Ruby library, so clients can now use Deltacloud
without starting a web server. The blog[2] post I mentioned above includes
examples of how to use this feature. Please mind that this feature is also
experimental, and we can't guarantee that the drivers API does not change in
future (which is unlikely ;-))
* A new collection, 'metrics', was brought in to support Amazon CloudWatch
metrics. To use this feature, you need to enable 'CloudWatch' support when
launching the instance by using the 'metrics=1' parameter.
* We're now in process of switching from different testing suites (rspec,
test::unit, cucumber, etc...) to use purely 'minitest'[3].
* A lot of Ruby 1.9<=>1.8 compatibility bugs have been fixed and Deltacloud API
should now run smoothly on MRI 1.9, including all our testing suites.
* A lot of small improvements have been made in various drivers. OpenStack drivers
now come with v2 API support (and keystone authentication), EC2 adds a new
hardware profile (m1-medium), RHEV-M and VSphere are now more precise in error
reporting, etc.
* A new driver was contributed from Fujitsu (Fujitsu Global Cloud Platform - FGCP)[3]
* Tons of networking stuff have been done on the CIMI front-end side, and the CIMI
client application got support for additional drivers.
* The website got fresh new look and content update[4] (big thanks to Dagmar!!!)
There are other minor changes which are not mentioned here. If you have any
questions or suggestions, please don't hesitate to ask on #deltacloud-internal
or #deltacloud @ freenode IRC channels or contact us.
The packages for Fedora 17 and Fedora 18 are ready for testing here:
https://admin.fedoraproject.org/updates/deltacloud-core-1.0.0-1.fc17
[1] https://git-wip-us.apache.org/repos/asf?p=deltacloud.git;a=blob;f=NEWS
[2] http://mifo.sk/deltacloud-as-library-and-more
[3] http://www.fujitsu.com/global/solutions/cloud/solutions/global-cloud-plat...
[4] http://deltacloud.apache.org/
Michal Fojtik
http://deltacloud.org
mfojtik(a)redhat.com
11 years, 9 months
