aeolus-devel April 2013

aeolus-devel@lists.fedorahosted.org

21 participants
12 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

conductor / aeolus-cli in fedora
by Mo Morsi 29 Apr '13

29 Apr '13

Is there any interest in continuing to support conductor / aeolus-cli in Fedora? The packages are currently broken there and from what I gather the team's been more focused on development and releasing gems recently. Unless there are any objections, I will retire the packages. If there is demand for support in Fedora in the future, we can easily loop back around then. -Mo

6 7

Aeolus Web interface not loading
by Rajat Gupta 25 Apr '13

25 Apr '13

Hi List, I recently installed aeolus on my machine . On loading the web interface at https://localhost/conductor/api ,but the browser says "Service is Unavailable" . For this I followed the instructions to edit Config file in etc/selinux as mentioned on the FAQ page , and rebooted the system , but it wasn't of any help . Please guide what else can be done . Regards, Rajat Gupta

2 1

Musing: Hyperscale computing and us
by Matt Wagner 17 Apr '13

17 Apr '13

There's been some buzz about HP's new "Moonshot" server: http://h17007.www1.hp.com/us/en/enterprise/servers/products/moonshot/index.… The main page is kind of marketing-speaky, but if you poke around it becomes clear what it is: a 4.3U[1] enclosure that fits "up to 45 hot-pluggable, efficient, extreme low-energy servers." They're dual-core 2 GHz Atoms, with a single memory slot up to 8GB, and a single 2.5" disk. I had lunch yesterday with some people who happened to be pretty familiar with this, and what's dubbed the "hyperscale" paradigm. The idea is that, instead of some dense servers and running VMs on them, you go for a massive number of very low-power servers. These Atoms seem to use something in the ballpark of 10W, but there's also a lot of interest in ARM chips where you can get much lower usage. And apparently, 45 nodes in 4.3U is nothing. Look at HP's Redstone[2] for example, which fit 288 ARM chips into a 4U chassis. So on the surface, this is wholly irrelevant to cloud computing. In fact, if anything, it seems like it undermines the whole premise of virtualization. But it occurs to me that, if it's possible to have hundreds, even thousands, of servers in a single rack, the way people manage them is probably going to change. I think you're almost going to want to treat them like cloud instances -- boot them with some premade image, do your work on them, and then spin them down, treating them as stateless. Maybe it's a one-off compute job (using Hadoop or something), or maybe you're hosting some sites and want to just power up additional servers as load grows. I think you're going to want to stop treating them as always-on servers with a fixed role, and view them exactly the same was as someone views a cloud instance, but backed by hardware. I think it's too soon to be able to do a lot, but I think this is something worth thinking about. Can we effectively bring what we do in the cloud to "hyperscale" physical nodes? -- Matt [1] Yes, 4.3U. And yes, the idea of fractional rack units really bugs me. [2] http://www.theregister.co.uk/2011/11/01/hp_redstone_calxeda_servers/

3 3

[aeolus-incubator/tim] a6ecc0: Added doc from wiki
by Jason Guiditta 16 Apr '13

16 Apr '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: a6ecc0bc1d3dfdd0bbb24c78b795baef4a8f9de5 https://github.com/aeolus-incubator/tim/commit/a6ecc0bc1d3dfdd0bbb24c78b795… Author: Martyn Taylor <mtaylor(a)redhat.com> Date: 2013-04-16 (Tue, 16 Apr 2013) Changed paths: A doc/api/object_model.md A doc/api/rest/base_images.md A doc/api/rest/image_versions.md A doc/api/rest/index.md A doc/api/rest/provider_images.md A doc/api/rest/target_images.md A doc/api/rest/templates.md A doc/api/ruby/index.md A doc/contributing/exceptions.md A doc/contributing/index.md A doc/contributing/logging.md A doc/getting_started/imagefactory_setup.md A doc/images/object_model.png A doc/index.md Log Message: ----------- Added doc from wiki Commit: bc09d14c779fa5411f6800c0600c8d63dd972538 https://github.com/aeolus-incubator/tim/commit/bc09d14c779fa5411f6800c0600c… Author: jguiditta <jguiditt(a)redhat.com> Date: 2013-04-16 (Tue, 16 Apr 2013) Changed paths: A doc/api/object_model.md A doc/api/rest/base_images.md A doc/api/rest/image_versions.md A doc/api/rest/index.md A doc/api/rest/provider_images.md A doc/api/rest/target_images.md A doc/api/rest/templates.md A doc/api/ruby/index.md A doc/contributing/exceptions.md A doc/contributing/index.md A doc/contributing/logging.md A doc/getting_started/imagefactory_setup.md A doc/images/object_model.png A doc/index.md Log Message: ----------- Merge pull request #121 from mtaylor/doc Added doc from wiki Compare: https://github.com/aeolus-incubator/tim/compare/0f4c716c0dfc...bc09d14c779f

1 0

[aeolus-incubator/tim] 233035: Create gh-pages branch via GitHub
by Martyn Taylor 16 Apr '13

16 Apr '13

Branch: refs/heads/gh-pages Home: https://github.com/aeolus-incubator/tim Commit: 2330357f0e2bd2f6d1c3a2ab10d13a2dded2ac2d https://github.com/aeolus-incubator/tim/commit/2330357f0e2bd2f6d1c3a2ab10d1… Author: mtaylor <mtaylor(a)redhat.com> Date: 2013-04-16 (Tue, 16 Apr 2013) Changed paths: A images/body-bg.jpg A images/download-button.png A images/github-button.png A images/header-bg.jpg A images/highlight-bg.jpg A images/sidebar-bg.jpg M index.html M params.json A stylesheets/print.css M stylesheets/pygment_trac.css M stylesheets/stylesheet.css Log Message: ----------- Create gh-pages branch via GitHub

1 0

[aeolus-incubator/tim] 896532: Create gh-pages branch via GitHub
by Martyn Taylor 16 Apr '13

16 Apr '13

Branch: refs/heads/gh-pages Home: https://github.com/aeolus-incubator/tim Commit: 896532ba70fa16174251fc3fddf1c073bbe58072 https://github.com/aeolus-incubator/tim/commit/896532ba70fa16174251fc3fddf1… Author: mtaylor <mtaylor(a)redhat.com> Date: 2013-04-16 (Tue, 16 Apr 2013) Changed paths: A images/bg_hr.png A images/blacktocat.png A images/icon_download.png A images/sprite_download.png A index.html A javascripts/main.js A params.json A stylesheets/pygment_trac.css A stylesheets/stylesheet.css Log Message: ----------- Create gh-pages branch via GitHub

1 0

[aeolus-incubator/tim] 8fd8ca: Add Contributing Guide.
by Martyn Taylor 16 Apr '13

16 Apr '13

Branch: refs/heads/master Home: https://github.com/aeolus-incubator/tim Commit: 8fd8ca92eacc3a45e5a04eb3426a3ff17ba520a6 https://github.com/aeolus-incubator/tim/commit/8fd8ca92eacc3a45e5a04eb3426a… Author: Jason Guiditta <jguiditt(a)redhat.com> Date: 2013-04-11 (Thu, 11 Apr 2013) Changed paths: M README.rdoc Log Message: ----------- Add Contributing Guide. Closes issue #119 Commit: 0f4c716c0dfc381e53b8abccc19b1a3c0136d086 https://github.com/aeolus-incubator/tim/commit/0f4c716c0dfc381e53b8abccc19b… Author: mtaylor <mtaylor(a)redhat.com> Date: 2013-04-16 (Tue, 16 Apr 2013) Changed paths: M README.rdoc Log Message: ----------- Merge pull request #119 from jguiditta/contribute Contributer guide Compare: https://github.com/aeolus-incubator/tim/compare/c940c3d6a4cc...0f4c716c0dfc

1 0

JBug Talk: Becoming Cloud Agnostic using Deltacloud and Imagefactory
by Martyn Taylor 15 Apr '13

15 Apr '13

Gents, I got some really good feedback from my talk last night: Becoming Cloud Agnostic using Deltacloud and Imagefactory People are all for DC and CIMI and see Imagefactory as an extremely useful tool. Interestingly, it seems some folks are using tools like CFEngine for managing images and instances atm, which is extremely topical since that is one of the directions we'd like to go with Tim. If you'd like to reproduce the talk (which is actually a reproduction of my own and Michal's FOSDEM13 talk with a bit of wrapper) then you can get slides from the link below. Thanks to Jaromir for the excellent slide design and Michal for providing me with his great FOSDEM13 talk. Regards Martyn http://martyntaylor.fedorapeople.org/becoming_cloud_agnostic_using_deltaclo…

2 1

deltacloud as a lib and broker
by Jan Provazník 11 Apr '13

11 Apr '13

Hi, there was a discussion in the last weeks about the proposal to reduce Conductor into a broker. Martin with Tomas wrote nice summary here: https://github.com/aeolusproject/conductor/wiki/BrokerProject During this discussion we touched (again) the "Deltacloud as a lib" topic, Michal asked me to send a mail here if we have a feature request. If you look at the possible solutions (the link above), having this lib would be helpful in all three options. Although the broker could be implemented using DC as a separate service or as a rack mounted app, I think it's not an optimal solution: DC consumer is then dependent on this separate service, it adds another chunk into the chain that can fail and that a user has to take care of. If it's rack mounted into an app which uses it, then it solves the problem with setting up separate daemon, but communication between app and DC is technically same as if it was separate service (so then TCP connection from the app to the mounted DC is done anyway). And it adds another problem - a user has to take care of restricting access to the mounted DC api which is then exposed in the same way as the main app. From what I know there are two major reasons for having DC as a standalone service: - taking care of another API (on lib level) - it can be used by other no-ruby projects then I think that it wouldn't be so bad, because with DC as a lib: - you wouldn't have to support ruby deltacloud-client - maybe the classic DC API wouldn't be needed then and consumers who can't use DC lib directly would be satisfied with CIMI API (which you already have). But even if you keep classic DC API, it would be just simple wrapper around this lib which converts input/output into expected format. I think, this would also bring DC more audience. Obviously according to fog library popularity, ruby world wants a cloud lib and it's a pitty that the library is not Deltacloud. This lib would be also handy for the WingedMonkey project. Jan

7 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

aeolus-devel April 2013