aeolus-devel January 2013

aeolus-devel@lists.fedorahosted.org

39 participants
43 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

[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

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

Rails 3.0.x are not supported by upstream anymore
by Vít Ondruch 30 Jan '13

30 Jan '13

Hi, Just FYI, you probably have not noticed, but Rails 3.0.x are not supported anymore by upstream: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/G4… Vít

1 0

[aeolus-incubator/tim] 45eda1: ImageFactory OAuth request support
by Jason Guiditta 29 Jan '13

29 Jan '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 45eda1635f2b249cb032e212c572581431e481ce https://github.com/aeolus-incubator/tim/commit/45eda1635f2b249cb032e212c572… Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2013-01-25 (Fri, 25 Jan 2013) Changed paths: M README.rdoc M lib/image_factory/image_factory.rb A lib/image_factory/oauth/active_resource_oauth_client.rb M test/dummy/config/initializers/tim.rb M tim.gemspec Log Message: ----------- ImageFactory OAuth request support Adds in the ability to use 2 Legged OAuth for securing requests to imagefactory. Commit: d4f5a692c3c8a02ab3d2bab893c575b7d4414585 https://github.com/aeolus-incubator/tim/commit/d4f5a692c3c8a02ab3d2bab893c5… Author: jguiditta <jguiditt(a)redhat.com> Date: 2013-01-29 (Tue, 29 Jan 2013) Changed paths: M README.rdoc M lib/image_factory/image_factory.rb A lib/image_factory/oauth/active_resource_oauth_client.rb M test/dummy/config/initializers/tim.rb M tim.gemspec Log Message: ----------- Merge pull request #99 from mtaylor/OAuthSupport ImageFactory OAuth request support Compare: https://github.com/aeolus-incubator/tim/compare/bd51b70d25f8...d4f5a692c3c8

1 0

[PATCH imagefactory] Suggested patches to enable default network selection on RHEV
by Vagner Farias 28 Jan '13

28 Jan '13

Ensuring the default "rhevm" network is set if packages are updated and aeolus-configure is not run again. diff -uNr imagefactory-1.0.2/imgfac/builders/Fedora_rhevm_Builder.py imagefactory-1.0.2.network/imgfac/builders/Fedora_rhevm_Builder.py --- imagefactory-1.0.2/imgfac/builders/Fedora_rhevm_Builder.py 2012-09-11 18:52:19.000000000 -0300 +++ imagefactory-1.0.2.network/imgfac/builders/Fedora_rhevm_Builder.py 2013-01-28 01:11:07.860078324 -0200 @@ -213,6 +213,9 @@ if provider_data['target'] != 'rhevm': raise ImageFactoryException("Got a non-rhevm target in the vsphere builder. This should never happen.") + # If network_name is not set, let's set it to the default rhevm + provider_data['network_name'] = provider_data.setdefault('network_name','rhevm') + self.generic_decode_credentials(credentials, provider_data) # Deal with case where these are not set in the config file -- Vagner Farias vfarias(a)redhat.com

1 0

[PATCH iwhd] Suggested patches to enable default network selection on RHEV
by Vagner Farias 28 Jan '13

28 Jan '13

Enabling iwhd to use a variable setting for the network. diff -uNr iwhd-1.5/dc-rhev-image.c iwhd-1.5.network/dc-rhev-image.c --- iwhd-1.5/dc-rhev-image.c 2012-01-06 12:40:26.000000000 -0200 +++ iwhd-1.5.network/dc-rhev-image.c 2013-01-24 21:23:37.420097269 -0200 @@ -95,6 +95,7 @@ char *nfsdir; time_t import_timeout; char *cluster; + char *network_name; }; struct http_uri { @@ -1805,7 +1806,7 @@ if (rc < 0) goto err_xml; rc = xmlTextWriterWriteElement(writer, - BAD_CAST "rasd:Caption", BAD_CAST "Ethernet 0 rhevm"); + BAD_CAST "rasd:Caption", BAD_CAST "Ethernet 0"); if (rc < 0) goto err_xml; rc = xmlTextWriterWriteElement(writer, BAD_CAST "rasd:InstanceId", BAD_CAST "3"); @@ -1818,7 +1819,7 @@ BAD_CAST "rasd:ResourceSubType", BAD_CAST "3"); if (rc < 0) goto err_xml; rc = xmlTextWriterWriteElement(writer, - BAD_CAST "rasd:Connection", BAD_CAST "rhevm"); + BAD_CAST "rasd:Connection", BAD_CAST cfg->network_name); if (rc < 0) goto err_xml; rc = xmlTextWriterWriteElement(writer, BAD_CAST "rasd:Name", BAD_CAST "eth0"); @@ -2559,6 +2560,8 @@ cfg_veripick(&cfg.cluster, cfgname, jcfg, "cluster"); + cfg_veripick(&cfg.network_name, cfgname, jcfg, "network_name"); + json_decref(jcfg); jcfg = NULL; -- Vagner Farias vfarias(a)redhat.com

1 0

Notifications between Aeolus components
by Jan Provazník 28 Jan '13

28 Jan '13

Hi folks, I'd like to discuss a topic which was briefly touched on Aeolus developer Conference in Brno. Many components of Aeolus project need to send notifications to other components: Heat -> Conductor (deployment/instance state changes) Conductor -> Winged Monkey (deployment/instance state changes) Imagefactory -> Conductor (notifications about image build&upload state) DC tracker* -> Heat (notifications about instance state changes) DC tracker -> Conductor (notifications about other provider resource changes, realms availability, hw profile changes) * DC Tracker - this component is actually not agreed yet, it was just a proposal some time ago, but I believe this will be needed. As far as I know there is no a unified plan how to deal with notifications between components. At this point notifications are implemented only in Imagefactory. This implementation is for now quite simple - a notification callback is sent back as http PUT request. It doesn't cover any failure situations (network error, auth error, Conductor is not running...), so if a request is not successful, no retry is done. I think we need more robust notification system between all components above, this system should support at least: 1) retry on failure 2) keep correct order of notifications 3) support authentication And here it comes... Why not use a message bus (an AMQP implementation) for communication between all involved components? - it supports all required features out of the box - clients exists for all languages involved in Aeolus project - notifications will be solved in the same way between all components Or is there some other solution how to solve notifications as painless as possible while keeping required robustness? What is your preferred solution of this problem? Jan

14 36

RESTful API documentation tool and more
by Martin Povolny 28 Jan '13

28 Jan '13

Gentlemen, I would like to bring to your attention an interesting project by our brothers in arms from the Katello project "Apipie-rails". https://github.com/Pajk/apipie-rails The tool brings creating RESTful APIs in Rails to a new (higher) level. >From the endless list of benefits you get I pick a few: * declarative syntax (through DSL) * validators for parameters * versioning * possibility to reuse the definitions for (client) code generation or or test generation * actively maintained, tested * githup hosted * used in Katello and Foreman * 100% Ruby and Ruby on Rails Way(tm) Happy hacking! -- Martin Povolny <mpovolny(a)redhat.com> tel. +420777714458

1 0

Codeclimate metrics for Conductor and Tim
by Justin Clift 24 Jan '13

24 Jan '13

If anyone's interested, we have Codeclimate metrics for Conductor and Tim (was free :>). https://codeclimate.com/github/aeolusproject/conductor https://codeclimate.com/github/aeolus-incubator/tim Seems interesting, but not sure how useful/accurate it really is. + Justin -- Aeolus Cloud Evangelist http://www.aeolusproject.org

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel January 2013