aeolus-devel January 2013

aeolus-devel@lists.fedorahosted.org

39 participants
43 discussions

Aeolus Team Leads
by Martyn Taylor 14 Jan '13

14 Jan '13

Gents, We are stuck in a pattern where, after hours/days of frustrating debate, we create delicate balances of agreement on topics only to have our consensus break when a new point of view is interjected or another conversation takes place. I really think it is time to add some layer of leadership to the team. Our team is simply too large to act as a democracy. I realise that the Tech Cabal is an attempt to address the aforementioned problems, but I do not feel that adding another sub-democracy can help us in this issue. The Cabal has its advantages when trying to solve integration/cross project problems, but I don't think it helps us steer individual projects. I really think we need technical leads that have the power to make decisions, or at the very least to decide when debate is closed and carry forward ideas that have been agreed upon. This is how the majority of projects both inside and outside of RedHat operate. I'm not sure why we do not have this in Aeolus, but I'd be much happier in my position if I had some clear direction on approach, whether I agreed with that approach or not. Let me be clear and say I don't expect Team Leads to simply make all and every decision alone and dictate to the rest of the team. Rather, we need someone who listens to all points of view and makes a decision and takes responsibility for it. How do you guys feel about this idea? Would you be willing to give up some control for clear direction? Regards, Martyn

6 12

ActiveRecord SQL injection and secret_token.rb
by Vít Ondruch 14 Jan '13

14 Jan '13

Hi everybody, You probably noticed, that there was released new version of Ruby on Rails fixing CVE-2012-5664 vulnerability. The details how to exploit this vulnerability are very well described at Phusion's blog [1]. However, what is more important is, that since your application secret token is not that secret, i.e. it is published on github [2], cookies of Aeolus could be faked [3]. Katello seems to do better in this area [4] (although it was just quick look into code, not security audit :)). Please consider narrowing this situation. Thank you Vít [1] http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulnerability-hold-yo… [2] https://github.com/aeolusproject/conductor/blob/master/src/config/initializ… [3] http://biggestfool.tumblr.com/post/24049554541/reminder-secret-token-rb-is-… [4] https://github.com/Katello/katello/blob/master/src/config/initializers/secr…

5 6

RFC: Factory support for nested build requests
by Matt Wagner 10 Jan '13

10 Jan '13

Hi folks, This email is to solicit input on a discussion that came up on IRC tonight, with a proposal to have Image Factory allow us to request the builds of child objects at the same time we are requesting the builds for their parents. Jan and I hit an issue tonight with submitting builds to Image Factory. The problem is essentially caused by the fact that, in our new (reimplemented) build_all method[1], we submit a request to build a new image version, and the immediately commence building target images. This appears to typically work fine when building for a single provider, but when there are multiple providers, this often causes the build to fail, as we end up submitting the target_image builds before the image_version build has completed. In our discussion, we talked about the implementation of this. The "right way" in Conductor would be to set up a background task to handle this. We would submit a request to build an image version, and then wait for a callback from Factory saying it was done. When it was done, we would then submit tasks for each target image we wished to build. (We would have to do this eventually anyway, to allow us to automatically push the image when we got a callback that the build had completed. One-call build-and-push would help here, but this isn't what we're talking about in this email.) Ian proposed that this might be done in Factory itself: <imcleod> matty_dubs: Would it be super-helpful to you to be able to request child image types while the parent is still in progress? Because we could do that. We'd have to add some polling internal to factory, but it's not particularly onerous. My gut is that this would make things significantly simpler, at least on the Conductor side. We wouldn't need to worry about queuing tasks to be sent upon receipt of callbacks. It also just feels architecturally cleaner, to not have two applications that need to know a lot about the inner workings of the other. Ian is going to investigate a bit to get an estimate of how involved this would be. But in the event that it's not too involved, I propose that this would be the best course of action, versus us trying to implement the same sort of thing in Conductor. Do any of you folks have opinions on the matter? -- Matt [1] https://github.com/aeolusproject/conductor/blob/tim-stable-rebased/src/app/… -- specifically, line 95 does not wait

5 5

New RoR 2.x, 3.x exploit
by jzigmund＠redhat.com 10 Jan '13

10 Jan '13

"This module exploits a remote code execution vulnerability in the XML request processor of the Ruby on Rails application framework. This vulnerability allows an attacker to instantiate a remote object, which in turn can be used to execute any ruby code remotely in the context of the application." - from exploit's code [1] All description and all paths for exploitation: [2] Sum up all current RoR exploits: [3] [1] - https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits… [2] - https://community.rapid7.com/community/metasploit/blog/2013/01/09/serializa… [3] - http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html -- Jozef

4 5

[aeolus-incubator/tim] 27c49f: Update Tim to use Rails 3.2.11.
by Martyn Taylor 10 Jan '13

10 Jan '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 27c49f76cbeeddbfcb2c46f719c213c55c271d3e https://github.com/aeolus-incubator/tim/commit/27c49f76cbeeddbfcb2c46f719c2… Author: Jason Guiditta <jguiditt(a)redhat.com> Date: 2013-01-10 (Thu, 10 Jan 2013) Changed paths: M Gemfile.lock M tim.gemspec Log Message: ----------- Update Tim to use Rails 3.2.11. This release fixes some major security issues with rails, as can be seen in the links for issue #94 Commit: edff7f3a937b04362d2f18fe93bc0237a9e1fd11 https://github.com/aeolus-incubator/tim/commit/edff7f3a937b04362d2f18fe93bc… Author: mtaylor <mtaylor(a)redhat.com> Date: 2013-01-10 (Thu, 10 Jan 2013) Changed paths: M Gemfile.lock M tim.gemspec Log Message: ----------- Merge pull request #94 from jguiditta/rails_3.2.11 Move to newest Rails for major security update Compare: https://github.com/aeolus-incubator/tim/compare/2eba45410354...edff7f3a937b

1 0

State Transitions in ReST API
by Martyn Taylor 10 Jan '13

10 Jan '13

Gentlemen, We discussed how to model state transitions in the ReST API in the Tech Cabal and also offline for those who had particularly strong views. One of the objections brought forward was how to distinguish between clients (end users or applications) requesting state changes. For example: A developer decides he wants to terminate his running instances and system services that are used to notify conductor of when an instance has changed state. For example db-o-matic wants to tell conductor that the instance has now started. After some deliberation offline between myself and sseago and without objections from the Tech Cabal. We decided that the services and the end users should access different APIs and we should not add complexity into the end user API in order to support these system services. With this behind us. We then were able to move forward to make a decision on how to handle requests from a user to transition between states. Like in the developer example above. It was agreed that treating the State on an instance as simply an attribute on the resource (and not an action) was more inline with the ReST principal (Since adding actions breaks ReST principal of having a unified interface - in our case the unified interface is defined by HTTP). So, this now brings us to how we should represent these resources. I think this is something that can and should be decided on list. I have included below my opinion on how this should be represented, please add in your own comments. == So in my opinion we should model a state machine as an independent resource. When client wants to change the state of an instance, it looks at the state machine to figure out what are the possible states I can move to now. The instance can hold a reference to it's current state and the state machine. A simple example here: https://gist.github.com/4257951 Regards Martyn

8 15

RFC - API: Update of Provider Type
by Petr Blaho 10 Jan '13

10 Jan '13

Hi all, after some good points during sprint planning session I want to know every opinion about wether implement update action for Provider Type resource or not. The point is that updating Provider Type will mean changing of dependent Providers too. We cannot predict how will API users modify Provider Type. Change of Credential Definitions for that Provider Type could mean that all Providers of that Provider Type should be modified/recreated. And that is a problem. To make a better idea why user should use Provider Type API imagine a company with proprietary solution for managing VMs. They have Deltacloud Driver for their solution and they need to tell Conductor that Deltacloud has this Provider Type and how to work with it (which Credential Definitions it has ...) So, do you see a reason why build update action for Provider Type and which issues should be addressed w/r/t modifying Provider Type - Providers associations? Or should I work on other things and save time implementing feature which probably will have no use at all? IMHO I cannot imagine scenario where user needs to modify Provider Type but maybe I am wrong. -- Petr Blaho, pblaho(a)redhat.com Software Engineer, CloudForms

2 1

github issue labeling
by Martin Povolny 08 Jan '13

08 Jan '13

Hallo gentleman! I would love to assign labels to github issues for Conductor. Right now, I would love at least "bug", "feature". Maybe more labels if more then one can be assigned to one issue: "grave", "minor". Who has the powers to add labels? Can you add labels for me? Or can you give me the power to add labels? Or even do we need to discuss what labels to add? Happy hacking! -- Martin Povolny <mpovolny(a)redhat.com> tel. +420777714458

3 2

Reconciling names
by Angus Thomas 08 Jan '13

08 Jan '13

As discussed previously ( https://lists.fedorahosted.org/pipermail/aeolus-devel/2012-October/012923.h… ) there's a significant cost associated with the divergence of names between Aeolus and Red Hat's Cloudforms. The Aeolus community loses out in several ways: - Users of Cloud Engine are using terminology which doesn't apply upstream, putting a barrier between the Aeolus project and a good number of the users of our software. - As part of the productisation process, Red Hat translates all the strings in Conductor into nine different languages.[1] If the use of terms could be reconciled, Aeolus Conductor would immediately support nine languages, rather than supporting one. - The work required to maintain a separate set of terms for the Cloud Engine product is tedious and error-prone and falls entirely on people who are key contributors to Aeolus, and whose time could be better spent. Several rounds of shuttle diplomacy between the Aeolus community and Red Hat's product managers are now complete, and we have arrived at a final set of converged names. The final list is a significant set of changes from the current set of names used in Cloudforms, in response to the feedback from the Aeolus community. Here's the list, current names on the left, and the new name on the right: Image Template -> Component Outline Deployable -> AppForm Blueprint Deployment -> AppForm Pool Family/Environment-> Cloud Environment Pool -> Resource Zone Provider -> Cloud Resource Provider Hardware Profile -> Hardware Profile Provider Realm -> Provider Realm Frontend Realm -> Frontend Realm Image -> Image Assembly -> Assembly Instance -> Instance Catalog -> Catalog Config Server -> Config Server Please respond with +1 or objections. If you're new to the party, and are wondering if some of the new names could be changed, the answer is, "Probably not, at this stage". It has taken several rounds of discussion to get to this point. I'd strongly urge that we accept these names wholesale. Of course, the applications will continue to evolve, and names may well change in future, but we shouldn't miss this opportunity to reconcile the Aeolus project's names with Cloudforms. Please note that, as discussed in the Brno dev converence, we need to use the final set of names everywhere: - API - CLI - Controller names etc. - Web UI - Docs, Blogs, discussions So, there is going to be work to do to fix the entire application to use the correct names. Angus

18 22

Sprint review screencasts
by Jirka Tomasek 08 Jan '13

08 Jan '13

The Publicity Cabal has decided that it would be nice to record our sprint review presentations. We concluded that instead of recording whole sprint review call it would be better to make separate screencasts of the presented features. This approach makes each feature introduction shorter and noiseless. I have made a few tests and making screencast is fairy simple on Fedora. The recordmydesktop utility is already installed, I just installed GUI version gtk-recordmydesktop. Then I looked at http://www.youtube.com/watch?v=rWHXbkpJjGk for a couple of configuration advices. I prefer to use 25fps as it gives more fluid experience. The video file then grows quite big though, so set it based on the length of your presentation. Screencast I did has four minutes and video file has been around 70mb. Only tweak I had to do is to lower my mic sensitivity to avoid background noise. After you record the screencast, It is possible to upload it as it is or if you want to do more editing you need to use some video editor (Avidemux). If the video file is too large, you can use HandBrake to compress/convert it. Make sure that compressed video is still watchable:) Here is my Username/Password recovery screencast: http://www.youtube.com/watch?v=cur639p70Vs I will put this guide also to our wiki.

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel January 2013