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
Hi folks,
I was chatting a bit with Nitesh earlier today. (He wrote the
Aeolus-gui[1] app a while back, as you may recall.)
First off, it made me realize that the current situation is probably
unclear and alienating to people who aren't working on Aeolus full-time.
We've been talking a bit about whether we want to move away from
Conductor and in favor of a cloud broker approach, and then we've also
been talking about leaving Fedora, etc. I think we're moving in the
right direction and Aeolus will be a better project because of it, but
I'm not sure things have been made abundantly clear on the list. (Though
the wiki page helps.)
We were chatting a bit about what would be beneficial to the Aeolus
project as a whole, and floated the idea of some sort of lightweight
little app for managing cloud instances. And an idea sort of formed.
I think it would be interesting to build something like virt-manager[2],
but for managing cloud instances. Nothing fancy, and probably not
scalable to the enterprise market where people might be managing a
handful of instances.
It could just be a GUI client for Deltacloud. Maybe Qt, as Nitesh's
specialty.
I think there are a few reasons this could be pretty neat:
1.) It's easy to start small and scale up. Grab a list of instances from
Deltacloud, and let the user pick one to launch, on a given hardware
profile, and show a list of running instances. Over time, you can work
in reporting on statistics; disk/network/etc. management, etc.; a VNC
client where supported.
2.) You could support multiple providers the same way that virt-manager
supports multiple hypervisors -- just add multiple, and show them
separately. You can have a collapsible EC2 section and a collapsible
OpenStack section in the same app.
3.) It could be a fun project while we work on figuring out what we're
doing long-term.
4.) Most of our plans for an eventual cloud broker involve exposing a
Deltacloud API in Aeolus, that would transparently map to the ideal
cloud provider. Thus, this app could work with whatever we end up building.
5.) Having a lightweight client for whatever we're building would be
pretty useful, so we wouldn't be constrained to the API-only. And having
it be a generic client for clouds would emphasize our value-add, versus
being a heavy monolithic app.
6.) It might attract a different crowd than "enterprise hybrid cloud"
attracts. I think that's a good thing, especially upstream. Enterprise
hybrid cloud management is sort of a niche market. I think there are
many more people that would be interested in a lightweight little
desktop GUI for managing cloud instances, but that some of the problems
we'd be solving overlap a lot. IOW, I think it has potential to grow the
community, and that this would still translate into building a better,
more robust enterprise-y management app.
What do you think? Have I gone insane? Would this be a worthwhile endeavor?
-- Matt
[1] https://github.com/niteshnarayanlal/Aeolus-gui
[2] http://virt-manager.org/
Hallo all.
Together with Tomas, Jan and with contribution of many others we have
put together the proposal for the Broker project and put it into a wiki
page.
https://github.com/aeolusproject/conductor/wiki/BrokerProject
This page aims to explain what we want to do, why and how and also
suggest some ways how the goal can be reached.
We highly welcome your inputs, ideas, comments, opposing suggestions,
etc.
So, please, read the page and provide your feedback.
Regards!
--
Martin Povolny <mpovolny(a)redhat.com>
tel. +420777714458