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
11 years
conductor / aeolus-cli in fedora
by Mo Morsi
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
11 years, 1 month
Aeolus Web interface not loading
by Rajat Gupta
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
11 years, 1 month
Musing: Hyperscale computing and us
by Matt Wagner
There's been some buzz about HP's new "Moonshot" server:
http://h17007.www1.hp.com/us/en/enterprise/servers/products/moonshot/inde...
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/
11 years, 2 months
[aeolus-incubator/tim] a6ecc0: Added doc from wiki
by Jason Guiditta
Branch: refs/heads/master
Home: https://github.com/aeolus-incubator/tim
Commit: a6ecc0bc1d3dfdd0bbb24c78b795baef4a8f9de5
https://github.com/aeolus-incubator/tim/commit/a6ecc0bc1d3dfdd0bbb24c78b7...
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/bc09d14c779fa5411f6800c060...
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
11 years, 2 months
JBug Talk: Becoming Cloud Agnostic using Deltacloud and Imagefactory
by Martyn Taylor
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_deltac...
11 years, 2 months
deltacloud as a lib and broker
by Jan Provazník
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
11 years, 2 months
