Open Stack

Excerpts from John Speidel's message of 2013-08-27 09:29:18 -0700:
> Some services/components are related or have dependencies on other 
> services and components.As an example, in HDP, the Hive service depends 
> on HBase and Zookeeper.In Savanna, there is no way to express this 
> relationship.If a user wanted to deploy Hive, they would need to know to 
> install both HBase and Zookeeper a priori.Also, because the list of 
> service components(node processes) that is provided to a user to be used 
> in node groups is a flat list, only the component name gives any 
> indication as to what service the components belong to.Because of this, 
> it will likely be difficult for the user to understand exactly what 
> components are required to be installed for a given 
> service(s).Currently, the HDP stack consists of approximately 25 service 
> components.
> 
> 
> A primary reason that it isn't currently possible to express 
> service/component relationships is that topology is defined from the 
> bottom up.This means that a user first selects components and assigns 
> them to a node template.The users first interaction is with components, 
> not services.Currently, the user will not know if a given topology is 
> valid until an attempt is made to deploy a cluster and validate is 
> called on the plugin.At this point, if the topology were invalid, the 
> user would need to go back and create new node and cluster templates.
> 
> 
> 
> One way to express service relationships would be to define topology top 
> down, with the user first selecting services.After selecting services, 
> the related service components could be listed and the required 
> components could be noted. This approach is a significant change to how 
> Savanna currently works, has not been thoroughly thought through and and 
> is only meant to promote conversation on the matter.
> 
> 
> 
> After making new services available from the HDP plugin, it is clear 
> that defining a desired (valid) topology will be very difficult and 
> error prone with the current savanna architecture.I look forward to 
> discussing solutions to this matter with the community.
> 
> 

I understand that Savanna is laser-focused on Hadoop, however, it
seems really odd that Savanna would have its own way to define service
dependencies and deployments.

Heat is specifically meant to aid users in deploying multi-node services
with complicated dependency graphs. While I do agree this would be a
departure from the way Savanna works, it would also be in-line with what
Trove is doing for the same reasons.

So, as you move toward a service dependency graph, please consider using
Heat to orchestrate nodes, and enhancing it where Savanna needs it to
work better, rather than pouring more into a Savanna only solution. I
think in the end it will result in a simpler solution for Savanna, and
a better Heat as well.