Brainstorming tasks for next sprint

Tomas Sedovic tsedovic at redhat.com
Tue Feb 14 16:27:15 UTC 2012


On 02/13/2012 10:06 PM, Matt Wagner wrote:
> Hi all,
>
> As we start to wrap up bug-fixing, I was hoping to get a conversation
> going about what we need to tackle in upcoming sprints.
>
> Two things I think would be well-worth pursuing:
>
> a.) Actual OpenStack support. We (ostensibly) support Rackspace today,
> so this may be relatively straightforward. (Or those could be famous
> last words.) I think this is important for two reasons. The first is
> that OpenStack is a popular private-cloud offering, so we should support
> it alongside vSphere and RHEV. (It might also help those who keep trying
> to compare us *to* OpenStack understand that we occupy different
> spaces.)
>
> The second is that OpenStack powers several public clouds, and it would
> be fantastic if EC2 wasn't the only public cloud we supported. Obviously
> Rackspace's offering is using OpenStack or something extremely close.
> But Internap's Open Public Cloud[1] and HP's new HP Cloud are powered by
> OpenStack, so OpenStack support would get us compatibility with multiple
> public cloud providers.
>
> b.) Smarter matching of where we launch instances. I don't think this
> will be something we get right the first time -- it seems like there are
> a bunch of criteria that different people will weigh differently. But I
> think that's all the more reason to start out with something now and
> iterate over it. Our 'priority' concept helps somewhat, but it still
> feels pretty constrained. It feels like we've worked to make it easy to
> launch an instance in the cloud of your choosing (a noble enough goal, I
> admit), as opposed to allowing you to launch an instance and let
> Conductor do something intelligent on its own.
>
> What else do you think we should try to focus on?
>
> -- Matt
>
>
> [1]
> http://www.internap.com/flexible-cloud-hosting-solutions/enterprise-public-cloud-solutions/open-public-cloud-solutions/
> [2] http://www.hpcloud.com/http://www.hpcloud.com/

Thanks for getting the ball rolling, Matt.

With all that's been happening today, I didn't get to actually reading 
all your suggestions, sorry. I shall remedy that tomorrow and add 
feedback if I have any.

In a meeting with Angus here in Brno, two ideas popped up:

1) Display the list of importable instances.

    Instead of hunting in each provider's UI for the IDs of the images 
to import, the user would be able to see all the instances they could 
import, select them and import right from Conductor.

There are things to consider here (mainly performance), but Deltacloud 
allows image listing and this would improve the import-image usability.

2) Option to import instances.

    This is a bit tricky and it would probably require some manual work.

I think it's important to have, though. We would show the user (with 
appropriate privileges) all the instances that are running in a given 
provider that Conductor does not keep track of.

They could then select a pool, assign owners and anything else that's 
necessary for Conductor to bring those in.

Since these did not originate from Conductor, it's possible that some 
metadata will be missing -- but the same is true for imported images. 
And the benefit of using one tool to see the status of all your 
instances and being able to at least stop/restart them is huge.

If we can include an automatic importing with reasonable defaults (one 
click imports all instances into the default pool under the Admin user), 
this will become immediately usable to people who have some things 
running and just want to try Conductor by themselves.

3) Embrace cross-cloud migration, adopt Mo's Snap! tool, integrate it 
within our existing tools and make it even more awesome.

Thomas



More information about the aeolus-devel mailing list