February 2013 - aeolus-devel - Fedora mailing-lists

moving wiki content
by Mo Morsi 19 Jun '13

19 Jun '13

On the website mtg today we discussed moving the redmine wiki content to the individual github wiki's. Matt mentioned we have the capability to mass migrate redmine pages to github wiki pages so we're asking each individual subcommunity which pages they would like to be migrated to their wiki. The overall binding content will be moved to a combination of the conductor wiki and the aeolusproject.org github site wiki. The later isn't the best fit for the content (though alot of the content should go in the conductor wiki) but its the best option that we currently see atm. We threw around the idea of a mediawiki installation but as Matt mentioned we previously had one (got littered with spam) and none of us felt the effort of setting one up was worth the cycles atm (can be revisited in the future). If anyone has any additional suggestions, feel free to shout out here. We are looking at mid January as the cutoff date for this migration. We ask that a representative of each indivual subcommunity (deltacloud, imagefactory, oz, Tim, Heat, conductor, configure, aeolus-cli, and audrey) start looking at the redmine wiki and send us a list of the pages they want migrated. If you could send this to us by mid December that would be more than appreciated. Alternatively just migrate the wiki content you would like and just tell us (don't worry, we will find other things todo ;-) ). We will keep the redmine wiki around after the end of January in read only mode for historical / archival purposes. Though at some point in the far future we most likely will shut it down for good. -Mo

7 22

Initial Heat integration
by Tomas Sedovic 05 Mar '13

05 Mar '13

Dear Aeolus community, I've sent the first pull request integrating Heat with Conductor. Please have a look at the changes here: https://github.com/aeolusproject/conductor/pull/424 The pull request contains some observations, notes and rambling that should start a discussion on things I missed, did incorrectly, etc. For your convenience, I'm pasting it here as well: This is the first step towards full Heat integration. This routes deployment launching and querying for status to Heat. Launch-time parameters should just work, ditto for deleting the instances. This is mostly to give you guys a direction where I think this should go and to get comments and feedback. I don't think it's wise to merge it just yet -- we need to test it more, clean up the code, find the subtle things this breaks, etc. There are also a few issues that need fixing: * Heat's API supports atomic launch (i.e. rollback) but as far as I know, it's not been implemented yet * There's a bug in Heat that means the actual instance status isn't reported back correctly. If you launch a deployment and stop the instances out of band, Heat will show them as running. * Heat generates its own wealth of events that we should show in Conductor. They're currently being ignored. There's also an issue of performance. The way it's implemented now, every time you ask a deployment or an instance for a status, they request the Heat API for an up-to-date value. This happens a lot of times and it crawls the entire UI into a halt. I tried caching the value for the lifetime of the object as a simple workaround for rendering, but apparently, we (or Rails) are instantiating the same Deployment and Instance model objects over and over again when rendering the view so this didn't help much. The same issue is exists with a database backend as well, but Rails transparently caches the DB queries for each controller action. As a band-aid, I hooked `Heat::heat_request` to the Rails cache which deals with the issue. Eventually though, we need to think of a better way to solve it -- either by reducing the number of instances we create or by introducing a proper HTTP caching layer. Heat's API currently doesn't have any querying capabilities, so to list a few deployments, you have to send a separate request for each and then another request per instance to get instance properties as well. We could work with the Heat community to extend the API in a way that would mean issuing fewer requests. Before we commit to any optimizations though, it's better to have the raw thing so that we can measure where the bottlenecks actually lie. The advantage of using the built-in Rails caching API here is that you can disable it in the app config without changing anything in the code. Try it out ------------ You need Heat running with Deltacloud as a backend. I'll write a proper guide tomorrow (I need to package a couple of Python libraries to make things easier). If you're adventurous, you can go ahead and follow the respective guides: You can get Heat from here: <https://github.com/openstack/heat> No need to set up OpenStack, we're not using it. Though Heat does use a few OpenStack libraries for dependencies. Next, install `deltacloud_heat` which is a Deltacloud backend for Heat. It in turn uses the Deltacloud Python client. https://github.com/tomassedovic/deltacloud_heat https://github.com/tomassedovic/deltacloud There were some bugs fixed in the Deltacloud API that we require, you need at least version 1.1.0. We also need the latest Python client which I didn't get to submitting upstream yet. In short, use the server and the client from my fork above. To configure Heat to use Deltacloud, open the `/etc/heat/heat-engine.conf` file and add the following line at the end: cloud_backend=deltacloud_heat.clients Then open `/etc/heat/heat-engine.conf` and uncomment the last two lines: [paste_deploy] flavor = custombackend Start the Heat engine and api services (if you're going to use the Audrey features, start cloudwatch and cfn-api as well). That should be it.

2 3

[aeolus-incubator/tim] d89283: Added State Machine to target/provider images
by Jason Guiditta 28 Feb '13

28 Feb '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: d89283f432338a5b6bdab31d6707b24fa514e917 https://github.com/aeolus-incubator/tim/commit/d89283f432338a5b6bdab31d6707… Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2013-02-27 (Wed, 27 Feb 2013) Changed paths: M Gemfile A app/models/tim/fsm.rb M app/models/tim/provider_image.rb M app/models/tim/target_image.rb A db/migrate/20130211140935_add_fsm_fields_to_provider_image_and_target_image.rb M distros/rpm/rubygem-tim.spec M lib/tasks/tim_tasks.rake M test/dummy/db/schema.rb M tim.gemspec Log Message: ----------- Added State Machine to target/provider images Commit: ccdefe849ee544917e90401ab0dffdf4be94d561 https://github.com/aeolus-incubator/tim/commit/ccdefe849ee544917e90401ab0df… Author: jguiditta <jguiditt(a)redhat.com> Date: 2013-02-28 (Thu, 28 Feb 2013) Changed paths: M Gemfile A app/models/tim/fsm.rb M app/models/tim/provider_image.rb M app/models/tim/target_image.rb A db/migrate/20130211140935_add_fsm_fields_to_provider_image_and_target_image.rb M distros/rpm/rubygem-tim.spec M lib/tasks/tim_tasks.rake M test/dummy/db/schema.rb M tim.gemspec Log Message: ----------- Merge pull request #108 from mtaylor/state_machine Added State Machine to target/provider images Compare: https://github.com/aeolus-incubator/tim/compare/3cedd2509fbc...ccdefe849ee5

1 0

Aeolus Tech Cabal Meeting frequency
by Martyn Taylor 26 Feb '13

26 Feb '13

All, Due to the stand off nature of the Tech Cabal (we aim to not get involved unless issues are unsolvable via the usual means i.e. mail and irc), we have had nothing or very little on the Agenda for the past couple of month. Because of this I propose we change our meeting frequency to once per month. I also propose that we take the opportunity to give an overview of recent progress of each component, this way we can all keep a track of where each project is going and hopefully catch any potential integration problems early on. Could those in favour of changing the meeting frequency and adding an overview of each project in the monthly meeting please ack. I will take a majority decision to go ahead. Regards Martyn

7 6

Adopted by Red Hat OSAS team
by Justin Clift 25 Feb '13

25 Feb '13

Hi all, The Red Hat Open Source and Standards (OSAS) team have been kind enough to adopt me :), so I've moved teams as of yesterday. In theory they'll have me working on Gluster integration with OpenStack, and anything else the upstream Gluster Community needs. If there's any outstanding Aeolus stuff someone needs from me, please let me know / remind me and I'll try and get it to you in the near future. :) Regards and best wishes, Justin Clift -- Open Source and Standards @ Red Hat twitter.com/realjustinclift

5 6

Having woes with rake dc:create_user
by Dan Macpherson 21 Feb '13

21 Feb '13

Hi guys, I've been playing around with the Aeolus nightly builds over the last few weeks and am having mostly success in getting it working. However, this week, I've hit a roadblock related to creating the admin user. I run aeolus-configure on a clean installation and it fails upon admin user creation. So I run rake dc:create_user and get the following traceback: [root@aeolus aeolus-conductor]# RAILS_ENV="production" rake dc:create_user[admin,password,root@localhost.localdomain,Administrator,] --trace Using gem require instead of bundler ** Invoke dc:create_user (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute dc:create_user rake aborted! undefined method `active_privilege_target_types' for #<Class:0x00000005d72508> /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/dynamic_matchers.rb:55:in `method_missing' /usr/share/aeolus-conductor/app/models/role.rb:49:in `privilege_target_match' /usr/share/aeolus-conductor/app/models/pool_family.rb:86:in `derived_subtree' /usr/share/aeolus-conductor/app/models/permission.rb:138:in `update_derived_permissions' /usr/local/share/gems/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:559:in `_run__3098622491858983024__save__374501331206798678__callbacks' /usr/local/share/gems/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:405:in `__run_callback' /usr/local/share/gems/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:385:in `_run_save_callbacks' /usr/local/share/gems/gems/activesupport-3.2.12/lib/active_support/callbacks.rb:81:in `run_callbacks' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/callbacks.rb:264:in `create_or_update' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/persistence.rb:104:in `save!' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/validations.rb:56:in `save!' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/attribute_methods/dirty.rb:33:in `save!' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:264:in `block in save!' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:313:in `block in with_transaction_returning_status' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:208:in `transaction' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:311:in `with_transaction_returning_status' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:264:in `save!' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/validations.rb:41:in `create!' /usr/share/aeolus-conductor/app/services/registration_service.rb:42:in `block (2 levels) in save' /usr/share/aeolus-conductor/app/services/registration_service.rb:37:in `each' /usr/share/aeolus-conductor/app/services/registration_service.rb:37:in `block in save' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/connection_adapters/abstract/database_statements.rb:192:in `transaction' /usr/local/share/gems/gems/activerecord-3.2.12/lib/active_record/transactions.rb:208:in `transaction' /usr/share/aeolus-conductor/app/services/registration_service.rb:25:in `save' /usr/share/aeolus-conductor/lib/tasks/dc_tasks.rake:26:in `block (2 levels) in <top (required)>' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain' /usr/share/ruby/monitor.rb:211:in `mon_synchronize' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block (2 levels) in top_level' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `block in top_level' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `block in run' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/share/gems/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run' /usr/bin/rake:32:in `<main>' Tasks: TOP => dc:create_user ... which is weird because active_privilege_target_types seems to be defined in app/models/permissioned_object.rb Anyone know how I can jump this hurdle? Dan Macpherson Content Author Engineering Content Services Red Hat Asia Pacific Pty Ltd Brisbane, Australia e: dmacpher(a)redhat.com

2 2

[ANNOUNCE] Tim 0.3.0
by Jason Guiditta 20 Feb '13

20 Feb '13

Tim 0.3.0 has just been pushed to rubygems and tagged in github. It is a fairly minor release, but requires config changes to use the new functionality (described in the README). Changelog: Jason Guiditta (2013-02-19) - 3cedd25 Update for oauth dep and 0.3.0 Jason Guiditta (2013-02-06) - 64d30b8 Remove rake task for cucumber. Martyn Taylor (2013-01-22) - 45eda16 ImageFactory OAuth request support Jason Guiditta (2013-01-17) - bd51b70 Add summary of what Tim is, and link to presentation doc.

2 1

[aeolus-incubator/tim]
by Jason Guiditta 19 Feb '13

19 Feb '13

Branch: refs/tags/v0.3.0 Home: https://github.com/aeolus-incubator/tim

1 0

[aeolus-incubator/tim] 3cedd2: Update for oauth dep and 0.3.0
by Jason Guiditta 19 Feb '13

19 Feb '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 3cedd2509fbc5f822a527bebfde55d5fc6435e4e https://github.com/aeolus-incubator/tim/commit/3cedd2509fbc5f822a527bebfde5… Author: Jason Guiditta <jguiditt(a)redhat.com> Date: 2013-02-19 (Tue, 19 Feb 2013) Changed paths: M distros/rpm/build M distros/rpm/rubygem-tim.spec M lib/tim/version.rb Log Message: ----------- Update for oauth dep and 0.3.0

1 0

It's Friday -- what YouTube videos do we talk about all the time?
by Matt Wagner 16 Feb '13

16 Feb '13

Hi all, I first feel compelled to clarify that I did a lot of real work today. It occurs to me that there are certain Youtube clips that we discuss fairly often, and sort of just assume that everyone has seen them. (For example -- the Fish Slapping Dance, or the MongoDB Web Scale video.) I tried to catalog them, in a maybe-too-encyclopediac way, on this Etherpad doc: https://etherpad-aeolusproject.rhcloud.com/p/Team_Videos Did I miss any? I'm not really trying to catalog all of the epic videos on Youtube, just the ones that we've discussed repeatedly in #aeolus that new people might benefit from seeing, so they're not left wondering why we keep saying "Is that web scale?" or talking about pig farms. -- Matt

2 1

Who wants to update rails?
by John Eckersberg 15 Feb '13

15 Feb '13

We're still running on the 3.2.12-ish stack that I put in after the first round of security holes came through. There's been several more rounds and probably more to come, so we need to keep pulling in updates. I just took a brief stab at updating to 3.2.12 proper, and a bunch of tests exploded as usual. I don't have time at the moment to bang on it myself, so if anybody wants to jump on it, you can be a hero.

4 6

Tim Provider/Target Image FSM
by Martyn Taylor 12 Feb '13

12 Feb '13

All, After some discussion with a few folks from Imagefactory, Tim and conductor about how to handle cascade deleting in Aeolus, we came up with I think some reasonable amount of scope for each component. I've included this below. As a result, the image lifecycle management, relationships etc... shall be handled not in factory but in Tim. As a first step to adding in this functionality (particularly for cascade delete) I've created state machine to highlight all possible states and transitions for Provider and Target Images. I'd like to get some feedback on the FSM I've included in the mail to make sure it matches up with reality + is sensible. Regards Martyn Tim FSM Image Management Scope/Tasks: _Factory: _ * Will provide some method to delete a provider image o This will* include the ability to register a callback o This will* include the ability to pass in provider credential o This will NOT* enforce referential integrity o This wil NOT* add any validation o This will NOT* support ordering of tasks added on the queue. _Tim_ * Implement cascade deletion.. o This will enforce integrity and validation o Potential Active Record cascade problems we may need to override destroy. _Conductor_ * Investigation into the handling of Deployables with regards to image deletion o Depends on the outcome of the RFC: Template Versioning and Rename _Conductor__+ Tim_: * Investigation into the handing and processing of failed deletions (images in state FAILED_DELETE in Imagefactory) o Discussion + Should we keep parents objects hanging around in conductor + Does/Should conductor archeive deletions + What are the implications in the Conductor UI

1 1

[tim] Added State Machine to target/provider images (#108)
by jguiditta 12 Feb '13

12 Feb '13

You can generate a jpeg graph of the state machine defined in both the target_image and provider_image class (NOTE they both use the same state machine) using the following rake command: ``` rake state_machine:draw FILE=../../app/models/tim/target_image.rb CLASS=Tim::TargetImage rake state_machine:draw FILE=../../app/models/tim/provider_image.rb CLASS=Tim::ProviderImage ``` You can merge this Pull Request by running: git pull https://github.com/mtaylor/tim state_machine Or you can view, comment on it, or merge it online at: https://github.com/aeolus-incubator/tim/pull/108 -- Commit Summary -- * Added State Machine to target/provider images -- File Changes -- M Gemfile (1) A app/models/tim/fsm.rb (39) M app/models/tim/provider_image.rb (2) M app/models/tim/target_image.rb (2) A db/migrate/20130211140935_add_state_to_provider_image_and_target_image.rb (6) M test/dummy/db/schema.rb (2) M tim.gemspec (4) -- Patch Links -- https://github.com/aeolus-incubator/tim/pull/108.patch https://github.com/aeolus-incubator/tim/pull/108.diff

1 1

[PATCH conductor 0/1] RFC - Login page notice support
by Matt Wagner 11 Feb '13

11 Feb '13

Hi folks, Someone running a Cloud Engine demo instance was interested in displaying a message on the login page displaying some information about the system. Note that I am NOT proposing to merge this patch at this time; it's really a one-off hack. I'm sending it out (a) so people can sanity-check it, and (b) because I think it's a decent RFE that we might want to fold in upstream. There's a second patch I'll send in a moment, that goes to to the vendor/converge-ui checkout (from a separate repo). This is less of a disaster post-1.1, but this is for 1.1. -- Matt

1 3

Re: [tim] mock image building actually builds a image (#102)
by jguiditta 11 Feb '13

11 Feb '13

Basically I am thinking we want mock builds to continue being a no op (like pre-tim conductor behaviour). In order for that to happen, the template os name needs to use FedoraMock or RHELMock. When originally discovering this and discussing with Dev, the line of thought was have tim update the os template name on the fly when mock target is requested otherwise mock builds actually build a full blown image which mock does not need or use. --- Reply to this email directly or view it on GitHub: https://github.com/aeolus-incubator/tim/issues/102#issuecomment-13390743

1 0

Re: [conductor] Gettext conversion part #2 - t-keys with variables (#402)
by jguiditta 11 Feb '13

11 Feb '13

Sorry for closing/reopening, I needed to restart travis builds .. now it's 'Good to merge' so let's review it! --- Reply to this email directly or view it on GitHub: https://github.com/aeolusproject/conductor/pull/402#issuecomment-13388048

1 0

Re: [conductor] Gettext conversion part #2 - t-keys with variables (#402)
by jguiditta 11 Feb '13

11 Feb '13

Reopened #402. --- Reply to this email directly or view it on GitHub: https://github.com/aeolusproject/conductor/pull/402

1 0

Re: [conductor] Gettext conversion part #2 - t-keys with variables (#402)
by jguiditta 11 Feb '13

11 Feb '13

Closed #402. --- Reply to this email directly or view it on GitHub: https://github.com/aeolusproject/conductor/pull/402

1 0

Re: [conductor] Gettext conversion part #2 - t-keys with variables (#402)
by jguiditta 11 Feb '13

11 Feb '13

Reopened #402. --- Reply to this email directly or view it on GitHub: https://github.com/aeolusproject/conductor/pull/402

1 0

Re: [conductor] Gettext conversion part #2 - t-keys with variables (#402)
by jguiditta 11 Feb '13

11 Feb '13

Closed #402. --- Reply to this email directly or view it on GitHub: https://github.com/aeolusproject/conductor/pull/402

1 0

Performance Testing and view speed improvements
by Francesco Vollero 08 Feb '13

08 Feb '13

Hello List, during a small dive into a system with aeolus for one colleague, I discovered that some views was really slow and seems that happen in randomic way. This reason gave me the impression that we should do some benchmarks not with a mere ab or time curl but actually measuring the load time of the transaction[1], because this will, from my point of view identify possible holes/misconfigurations or simply things we forgotten to optimize/fix. Also the video cited in [1] enlighted me on what really count to be measured. To measure the transaction response, we can use a tool, Apache JMeter[2]. With this we will record a session of our interest and execute the load test on it. [3] Hope to have your feedback on this, Cheers, -FV [1] http://blip.tv/clojure/craig-andera-performance-in-the-wild-5970188 [2] http://jmeter.apache.org/ [3] http://www.ibm.com/developerworks/java/library/j-ap04088/

2 2

[PATCH aeolus-configure] Suggested patches to enable default network selection on RHEV
by Vagner Farias 08 Feb '13

08 Feb '13

Hello, Currently there's no way to select which default logical network to use when configuring RHEV Resource Providers. This can be very tricky on medium or large networks in which the default "rhevm" network is used only for management. In future RHEV/oVirt releases administrators most likely won't give users permissions on rhevm network. Although there are initiatives to change how aeolus manages networks, perhaps a short term solution could be implemented until that time comes so that it's not required to change a hard coded setting in the code whenever the network to be used is different from "rhevm" To achieve this, I patched the following components: a) aeolus-configure, so that "network_name" becomes a required configuration for RHEV resource providers. b) iwhd, enabling it to use a variable setting for the network. c) imagefactory, in order to set "rhevm" as the default network if the packages are updated and aeolus-configure is not run again. Probably the default network could be set in iwhd, but I thought it was easier to set it in imagefactory. Notice that I'm not using the latest releases, but the ones used in CloudForms 1.1.1. Unfortunately I don't have the resources to test the patches in other releases. I don't know which would be the best option to send the patches, so I'll include one per message. diff -uNr aeolus-configure-2.8.11/conf/rhevm_configure aeolus-configure-2.8.11.network/conf/rhevm_configure --- aeolus-configure-2.8.11/conf/rhevm_configure 2012-10-25 19:15:06.000000000 -0200 +++ aeolus-configure-2.8.11.network/conf/rhevm_configure 2013-01-24 20:34:21.434972317 -0200 @@ -27,4 +27,5 @@ # deltacloud_password: password # deltacloud_api: https://rhevm.server.com:8443/api # deltacloud_data_center: data center id + # network_name: rhevm # push_timeout: 1800 diff -uNr aeolus-configure-2.8.11/recipes/aeolus/manifests/profiles/rhevm/instance.pp aeolus-configure-2.8.11.network/recipes/aeolus/manifests/profiles/rhevm/instance.pp --- aeolus-configure-2.8.11/recipes/aeolus/manifests/profiles/rhevm/instance.pp 2012-10-25 19:15:06.000000000 -0200 +++ aeolus-configure-2.8.11.network/recipes/aeolus/manifests/profiles/rhevm/instance.pp 2013-01-24 20:24:40.094971363 -0200 @@ -19,14 +19,16 @@ $deltacloud_password, $deltacloud_api, $deltacloud_data_center, - $push_timeout) + $push_timeout, + $network_name) { aeolus::rhevm::validate{"RHEV NFS export validation for ${name}": rhevm_rest_api_url => "$deltacloud_api", rhevm_data_center => "$deltacloud_data_center", rhevm_username => "$deltacloud_username", rhevm_password => "$deltacloud_password", - rhevm_nfs_export => "$nfs_export" + rhevm_nfs_export => "$nfs_export", + rhevm_network_name => "$network_name" } file {"$nfs_mount_point": diff -uNr aeolus-configure-2.8.11/recipes/aeolus/manifests/rhevm/validate.pp aeolus-configure-2.8.11.network/recipes/aeolus/manifests/rhevm/validate.pp --- aeolus-configure-2.8.11/recipes/aeolus/manifests/rhevm/validate.pp 2012-10-25 19:15:06.000000000 -0200 +++ aeolus-configure-2.8.11.network/recipes/aeolus/manifests/rhevm/validate.pp 2013-01-24 21:10:21.458125960 -0200 @@ -1,5 +1,5 @@ -define aeolus::rhevm::validate($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export){ - $result = rhevm_validate_export_type($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export) +define aeolus::rhevm::validate($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export,$rhevm_network_name){ + $result = rhevm_validate_export_type($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export,$rhevm_network_name) notify {"${name}": message => "the RHEV NFS export is on the correct storage domain and has type 'export' => ${result}" } diff -uNr aeolus-configure-2.8.11/recipes/aeolus/templates/rhevm.json aeolus-configure-2.8.11.network/recipes/aeolus/templates/rhevm.json --- aeolus-configure-2.8.11/recipes/aeolus/templates/rhevm.json 2012-10-25 19:15:06.000000000 -0200 +++ aeolus-configure-2.8.11.network/recipes/aeolus/templates/rhevm.json 2013-01-24 20:32:32.964075078 -0200 @@ -10,6 +10,7 @@ "nfs-host": "<%= params['nfs_server'] %>", "api-url": "<%= params['deltacloud_api'] %>", "cluster": "_any_", + "network_name": "<%= params['network_name'] %>", "timeout": <%= params['push_timeout'] %> }<%= remaining_instances.zero? ? nil : ',' %> <% end -%> -- Vagner Farias vfarias(a)redhat.com

2 2

[aeolus-incubator/tim] 64d30b: Remove rake task for cucumber.
by Martin Povolny 06 Feb '13

06 Feb '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 64d30b8897c8f650e23099372ea2fd1830a2c9a1 https://github.com/aeolus-incubator/tim/commit/64d30b8897c8f650e23099372ea2… Author: Jason Guiditta <jguiditt(a)redhat.com> Date: 2013-02-06 (Wed, 06 Feb 2013) Changed paths: R lib/tasks/cucumber.rake Log Message: ----------- Remove rake task for cucumber. This is unused and was causing cucumber to run twice in the host app, if the host used cucumber. Commit: f4a150a0b605b021c4442682d9707e1949d9a6ae https://github.com/aeolus-incubator/tim/commit/f4a150a0b605b021c4442682d970… Author: Martin Povolny <mpovolny(a)redhat.com> Date: 2013-02-06 (Wed, 06 Feb 2013) Changed paths: R lib/tasks/cucumber.rake Log Message: ----------- Merge pull request #107 from jguiditta/remove_cucumber_task Remove rake task for cucumber. Compare: https://github.com/aeolus-incubator/tim/compare/d4f5a692c3c8...f4a150a0b605

1 0

RFC - Messaging over social networks
by Angus Thomas 05 Feb '13

05 Feb '13

This is a problem which I've been thinking about in the context of Winged Monkey, but it is more generally applicable. We want Winged Monkey to be available on people’s phones, tablets etc so that they can see the state of running instances, receive notifications whenever there’s an outage etc.. So long as the users are standing fairly near the server which is running Winged Monkey, and can get wifi connectivity to the same network that the server is on, then it’s all relatively simple. However, as soon as users step outside the building, it all gets a bit more complex. In order for the users’ phone to be able to connect over the internet to the Winged Monkey server, then either the phone is going to need to have a VPN connection, which is a significant overhead, or the Winged Monkey server instance is going to have to be directly accessible over the internet. A lot of the organisations which are potential users of Winged Monkey wouldn’t be prepared to do that. We could use a social network as a messaging conduit between the Winged Monkey server and a client application on users’ phones. For the rest of this mail, I’ll expand in this in the context of Twitter. I don’t *think* this use would be a violation the Twitter’s terms of service. ( https://twitter.com/tos ). There are several public social networks which could serve the purpose... So, here’s how this could work: * The Winged Monkey server would register a Twitter account, with protected tweets. * A user would install and run the Winged Monkey phone app. The first run would also create a protected Twitter account, and when the user authenticates, the two Twitter accounts start following each other. * Thereafter Winged Monkey and the phone app use tweets to communicate over the internet, sending instructions, status updates etc. as strings up up to 140 characters. So long as both the server and the client app poll frequently for new tweets, the responsiveness should be acceptable to users. Some of the benefits are: * The communications are authenticated, with access permission which can be very quickly revoked by unfollowing an account which is no longer supported. * The communications are also (moderately) secure, in the sense that tweets from and between protected accounts aren’t generally readable. * The timelines of the accounts constitute an audit history of events etc.. It would be trivial to scrape that audit history from Twitter if required. * The principle benefit, though, is that the requirement for the Winged Monkey server to be directly accessible over the internet is removed. So long as the Winged Monkey server can make a client connection to Twitter.com, stuff just works. I’m not pretending that this is a flawless proposition, but I think there’s enough of an idea here to want feedback. I’d love to hear a better way to solve the problem. Angus

10 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel February 2013