moving wiki content
by Mo Morsi
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
10 years, 10 months
Initial Heat integration
by Tomas Sedovic
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.
11 years, 1 month
Aeolus Tech Cabal Meeting frequency
by Martyn Taylor
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
11 years, 1 month
Adopted by Red Hat OSAS team
by Justin Clift
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
11 years, 1 month
Having woes with rake dc:create_user
by Dan Macpherson
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
11 years, 1 month
[ANNOUNCE] Tim 0.3.0
by Jason Guiditta
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.
11 years, 2 months
It's Friday -- what YouTube videos do we talk about all the time?
by Matt Wagner
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
11 years, 2 months
