On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote: > Heat Developers, > > I am one of the core developers for Neutron who is lately working on the > concept of "Network Topologies". I want to discuss with you if the > following blueprint will make sense to have in heat or neutron code: > https://blueprints.launchpad.net/neutron/+spec/network-topologies-api > > Basically, I want to let tenants “save”, “duplicate” and “share” network > topologies by means of an API and a standardized JSON format that describes > network topologies. This google document provides detailed description: > https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit# > > There is a concern in Neutron of not duplicating efforts done by Heat team > and also to find the right place for this API. > > The intended work does NOT include any application driven orchestration > system, does NOT include any already existing or vender-specific standard > format for describing topologies, actually we want to standardized one > based on Neutron but it is still on discussion. > > If Heat developers could provide their point of view about this proposal, > wether it should be moved to Heat or it is fine to keep it in Neutron.
This seems related to a discussion I had last week re the Neutron services insertion and chaining functionality: https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering It does seem that you (Neutron) are moving towards functionality which requires more explicit management of dependencies, state and workflow, such that it may make sense to implement, some of it at least, in Heat. My opinion is that we should expose all of the underlying Neutron capabilities (individual bits of functionality) via Heat resources, which I think we're currently doing quite well (see [1] for the current list of supported functionality) Then any functionality requiring aggregation of resources where dependencies and state are used to create a workflow, should probably happen in Heat, IMHO. It doesn't make sense to me to have two projects building a dependency graph, managing state, and orchestrating workflow for the same underlying Neutron features. We should definitely continue these discussions so we can figure out where the most appropriate integration points may be. Steve [1] http://docs.openstack.org/developer/heat/template_guide/index.html _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
