aeolus-devel February 2013

aeolus-devel@lists.fedorahosted.org

24 participants
24 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel February 2013