aeolus-devel July 2011

aeolus-devel@lists.fedorahosted.org

47 participants
216 discussions

[PATCH aeolus] Removed footer links
by Angus Thomas 21 Jul '11

21 Jul '11

From: Angus Thomas <athomas(a)redhat.com> --- src/app/views/layouts/application.haml | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/src/app/views/layouts/application.haml b/src/app/views/layouts/application.haml index dcb18e6..167ed96 100644 --- a/src/app/views/layouts/application.haml +++ b/src/app/views/layouts/application.haml @@ -48,8 +48,4 @@ %footer.standard .container = image_tag('footer-rhlogo.png', :id => 'logo') - %nav.footer - %a{:href => '#'} Disclaimer - %a{:href => '#'} Terms of Use - %a{:href => '#'} Support %span.copyright Copyright © 2011 Red Hat, Inc. All Rights Reserved. -- 1.7.4.4

2 1

[PATCH conductor 1/2] provider feature updated to use element ids
by Tomas Hrcka 21 Jul '11

21 Jul '11

--- src/features/provider.feature | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/features/provider.feature b/src/features/provider.feature index ef89ea5..eb61f40 100644 --- a/src/features/provider.feature +++ b/src/features/provider.feature @@ -49,7 +49,7 @@ Feature: Manage Providers Scenario: Create a new Provider Given I am on the providers page And there is not a provider named "testprovider" - When I follow "New Provider" + When I follow "new_provider_button" Then I should be on the new provider page When I fill in "provider[name]" with "testprovider" And I fill in "provider[url]" with "http://localhost:3001/api" @@ -62,12 +62,12 @@ Feature: Manage Providers Scenario: Create a new Provider failure when using wrong url Given I am on the providers page And there is not a provider named "testprovider" - When I follow "New Provider" + When I follow "new_provider_button" Then I should be on the new provider page When I fill in "provider[name]" with "testprovider" And I fill in "provider[url]" with "http://localhost:3010/api" And I select "Amazon EC2" from "provider_provider_type_id" - And I press "Save" + And I press "provider_submit" Then I should be on the providers page And I should see "Failed to connect to Provider" @@ -79,7 +79,7 @@ Feature: Manage Providers And this provider has a provider account When I go to the providers page And I check "provider1" provider - And I press "Delete" + And I press "delete_button" And there should not exist a provider named "provider1" And there should not be any hardware profiles And there should not be a provider account -- 1.7.4.4

2 4

Test
by Maros Zatko 21 Jul '11

21 Jul '11

This is a test, please ignore.

1 0

Modify deployment and sug. deployable features
by Jirka Tomasek 21 Jul '11

21 Jul '11

This patchset modifies deployment and suggested deployale features to use element reconition by id

2 7

Aeolus Community Release 0.3.0 Upcoming
by Mike Orazi 21 Jul '11

21 Jul '11

We’ve seen quite a lot of good work going on since the last release! It feels like it is about the right time to cut and announce the 0.3.0 release. In order to get the release process rolling, I’d like to propose a few milestones over the course of the next week: * All ACK-ed patches for conductor land in the next branch by Wednesday (July 20) * Ensure conductor v0.3.0 tag is created in git by Wednesday (July 20) * Create a 0.3.x branch to track any maintenance fixes for conductor (July 20) * imagefactory, oz and iwhd tarballs available by Wednesday (July 20) * Finalize aeolus-configure for 0.3.0 release by Wednesday (July 20) * Build Fedora 14 RPMs of all components & promote to: http://repos.fedorapeople.org/repos/aeolus/conductor/0.3.0 Does the plan work for the various maintainers? Are there any changes that we should be trying to get into 0.3.0 that won’t be ready for Wednesday? Thanks, Mike

8 17

[PATCH conductor] BZ 723529 - remove PREFIX from /etc/sysconfig/aeolus-conductor
by Richard Su 21 Jul '11

21 Jul '11

Changing the value breaks aeolus-configure. We've elected to fix this after the beta release. Removing it for now to minimize confusion. --- conf/aeolus-conductor.sysconf | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/conf/aeolus-conductor.sysconf b/conf/aeolus-conductor.sysconf index f6b1b9b..50c450e 100644 --- a/conf/aeolus-conductor.sysconf +++ b/conf/aeolus-conductor.sysconf @@ -14,5 +14,3 @@ #CONDUCTOR_USER=aeolus #CONDUCTOR_GROUP=aeolus -# URL prefix for Rails application -#PREFIX=/conductor -- 1.7.4.4

1 1

[PATCH configure] BZ 723585 - Modified default hwp1 to be compatible with EC2, RHEV, and vSphere
by Richard Su 20 Jul '11

20 Jul '11

Removed provider specific hardware profiles for RHEV and vSphere. --- recipes/aeolus/manifests/conductor.pp | 4 ++-- recipes/aeolus/manifests/rhevm.pp | 12 +----------- recipes/aeolus/manifests/vmware.pp | 7 ------- 3 files changed, 3 insertions(+), 20 deletions(-) diff --git a/recipes/aeolus/manifests/conductor.pp b/recipes/aeolus/manifests/conductor.pp index afd55e5..d7bfb79 100644 --- a/recipes/aeolus/manifests/conductor.pp +++ b/recipes/aeolus/manifests/conductor.pp @@ -139,9 +139,9 @@ class aeolus::conductor::seed_data { require => Aeolus::Site_admin["admin"] } aeolus::conductor::hwp{"hwp1": - memory => "1", + memory => "512", cpu => "1", - storage => "1", + storage => "", architecture => "x86_64", require => Aeolus::Site_admin["admin"] } diff --git a/recipes/aeolus/manifests/rhevm.pp b/recipes/aeolus/manifests/rhevm.pp index de6f4fd..daa84d2 100644 --- a/recipes/aeolus/manifests/rhevm.pp +++ b/recipes/aeolus/manifests/rhevm.pp @@ -27,16 +27,6 @@ class aeolus::rhevm inherits aeolus { File["/etc/rhevm.json"], File["/etc/iwhd/conf.js"]]} - aeolus::conductor::hwp{"rhevm-hwp": - memory => "512", - cpu => "1", - storage => "1", - architecture => "x86_64", - require => Aeolus::Site_admin["admin"] } - - # break up aeolus::provider into its individual steps for two reasons: - # 1. deltacloudd expects "rhevm", imagefactory expects "rhev-m" passed through by conductor - # 2. rhevm-hwp must exist before creating provider aeolus::deltacloud{"rhevm": provider_type => 'rhevm', endpoint => "$rhevm_deltacloud_powershell_url", @@ -45,7 +35,7 @@ class aeolus::rhevm inherits aeolus { aeolus::conductor::provider{"rhevm": type => "rhevm", url => "http://localhost:${rhevm_deltacloud_port}/api", - require => [Aeolus::Deltacloud["rhevm"],Aeolus::Conductor::Hwp["rhevm-hwp"]]} + require => Aeolus::Deltacloud["rhevm"]} # TODO: # 1. since we have credentials, create provider account diff --git a/recipes/aeolus/manifests/vmware.pp b/recipes/aeolus/manifests/vmware.pp index 61e861d..4772b15 100644 --- a/recipes/aeolus/manifests/vmware.pp +++ b/recipes/aeolus/manifests/vmware.pp @@ -4,13 +4,6 @@ class aeolus::vmware inherits aeolus { mode => 755, require => Package['aeolus-conductor-daemons'] } - aeolus::conductor::hwp{"vsphere-hwp": - memory => "256", - cpu => "", - storage => "", - architecture => "x86_64", - require => Aeolus::Site_admin["admin"] } - aeolus::deltacloud{"vsphere": provider_type => 'vsphere', endpoint => "$vmware_api_endpoint", -- 1.7.4.4

2 1

Proposed revisions to aeolus-image invocation and object names
by Ian McLeod 20 Jul '11

20 Jul '11

Folks, Based on some IRC discussions over the last week with various people, I'd like to propose the following changes to the invocation options supported by aeolus-image: 1) Remove the ability to push to a provider via an image UUID - This was intended as a "convenience" option but has led to some confusion, primarily because it can only be done once for a single provider. 2) Add the ability to push to a provider via a target_image UUID - This would allow, for example, building an EC2 target_image and then pushing it to different regions (providers) at different times via discrete commands. Our documentation should clarify that pushing build UUIDs or target_image UUIDs is only guaranteed "safe" (that is, to produce identical provider_images) for upload style clouds. Snapshot style cloud provider_images are created at push-time and may differ from earlier pushes if the underlying repos have changed. Finally, I think we should consider renaming both the "image" object type and possibly the "provider_image" object type. Recall that our revised object model is described in rough terms in Mark's aeolus-devel post here: https://fedorahosted.org/pipermail/aeolus-devel/2011-May/001667.html The term "image" in the wider Cloud universe is almost always used to describe a machine image or snapshot that can be launched to produce an instance. The naming in the above post (which is what we currently use in iwhd, Factory and Conductor) uses "image" in an entirely different and far more generic way. I think this choice of name is partly responsible, in part, of the confusion around "pushing an image" described above. A more reasonable name for these objects might be "base_image" or "image_family". We have chosen to use the name "provider_image" for objects that map more or less 1:1 with external objects that are called "images" (Amazon Machine Image, Rackspace Image, GoGrid Image, etc.) If we rename our current "image" type to something else, we might also consider renaming "provider_image" to just plain "image" so that our naming is more consistent with the external providers. Thoughts? -Ian

6 5

[PATCH imagefactory-console] Include git hash and timestamp in extra_release string
by steve linabery 20 Jul '11

20 Jul '11

Edit rake/rpmtask.rb to include git hash and timestamp values in the extra_release info --- rake/rpmtask.rb | 13 ++++++++++--- 1 files changed, 10 insertions(+), 3 deletions(-) diff --git a/rake/rpmtask.rb b/rake/rpmtask.rb index 7534693..129b745 100644 --- a/rake/rpmtask.rb +++ b/rake/rpmtask.rb @@ -18,6 +18,9 @@ module Rake # RPM build dir attr_accessor :topdir + # Include extra_release information in the rpm + attr_accessor :include_extra_release + def initialize(rpm_spec) init(rpm_spec) yield self if block_given? @@ -25,6 +28,7 @@ module Rake end def init(rpm_spec) + @include_extra_release = true @rpm_spec = rpm_spec # parse this out of the rpmbuild macros, @@ -72,17 +76,20 @@ module Rake directory "#{@topdir}/SPECS" desc "Build the rpms" - task :rpms => [rpm_file] + task :rpms, [:include_extra_release] => [rpm_file] # FIXME properly determine :package build artifact(s) to copy to sources dir - file rpm_file => [:package, "#{@topdir}/SOURCES", "#{@topdir}/SPECS"] do |t,args| + file rpm_file, [:include_extra_release] => [:package, "#{@topdir}/SOURCES", "#{@topdir}/SPECS"] do |t,args| + @include_extra_release = args.include_extra_release != "false" + git_head = `git log -1 --pretty=format:%h` + extra_release = "." + Time.now.strftime("%Y%m%d%H%M%S").gsub(/\s/, '') + "git" + "#{git_head}" cp "#{package_dir}/#{@name}-#{@version}.tgz", "#{@topdir}/SOURCES/" # FIXME - This seems like a hack, but we don't know the gem's name cp "#{package_dir}/#{(a)name.gsub('rubygem-', '')}-#{(a)version}.gem", "#{@topdir}/SOURCES/" cp @rpm_spec, "#{@topdir}/SPECS" sh "#{@rpmbuild_cmd} " + "--define '_topdir #{@topdir}' " + - "--define 'extra_release #{args.extra_release}' " + + "--define 'extra_release #{@include_extra_release ? extra_release : ''}' " + "-ba #{@rpm_spec}" end end -- 1.7.4.4

2 1

[PATCH aeolus-image] Include git hash and timestamp in extra_release string
by steve linabery 20 Jul '11

20 Jul '11

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel July 2011