Open Stack

Hi Edgar,

It seems like this blueprint is related more to building an api that
manages a network topology more than one that needs to build out the
dependencies between resources to help create the network topology. If we
are talking about just an api to "save", "duplicate", and "share" these
network topologies then I would agree that this is not something that Heat
currently does or should do necessarily.

I have been focusing primarily on front-end work for Heat so I apologize
if these questions have already been answered. How is this API related to
the existing network topology in Horizon? The existing network topology
can already define the relationships and dependencies using Neutron I'm
assuming so there is no apparent need to use Heat to gather this
information. I'm a little confused as to the scope of the discussion, is
that something that you are potentially interested in changing?

Steve, Clint and Zane can better answer whether or not Heat wants to be in
the business of managing existing network topologies but from my
perspective I tend to agree with your statement that if you needed Heat to
help describe the relationships between network resources then that might
be duplicated effort but if don't need Heat to do that then this blueprint
belongs in Neutron.

Thanks,
Tim





On 10/29/13 1:32 AM, "Steven Hardy" <shardy at redhat.com> wrote:

>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
>> Hello Folks,
>> 
>> Thank you Zane, Steven and Clint for you input.
>> 
>> Our main goal in this BP is to provide networking users such as Heat (we
>> consider it as a neutron user) a better and consolidated network
>>building
>> block in terms of an API that you could use for orchestration of
>> application-driven requirements. This building block does not add any
>> "intelligence" to the network topology because it does not have it and
>> this is why I think this BP is different from the work that you are
>>doing
>> in Heat.
>
>So how do you propose to handle dependencies between elements in the
>topology, e.g where things need to be created/deleted in a particular
>order, or where one resource must be in a particular state before another
>can be created?
>
>> The network topologies BP is not related to the Neutron Network Service
>> Insertion BP:
>> 
>>https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion
>>-c
>> haining-steering
>
>So I wasn't saying they were related, only that they both, arguably, may
>have some scope overlap with what Heat is doing.
>
>> I do agree with Steven that the insertion work add "intelligence"
>> (explicit management of dependencies, state and workflow) to the network
>> orchestration simply because user will need to know the insertion
>> mechanism and dependencies between Network Advances Services, that work
>>is
>> more into Heat space that the BP that I am proposing but that is just my
>> opinion.
>
>This seems a good reason to leverage the work we're doing rather than
>reinventing it.  I'm not arguing that Heat should necessarily be the
>primary interface to such functionality, only that Heat could (and
>possibly
>should) be used to do the orchestration aspects.
>
>> However, is there a session where I can discuss this BP with you guys?,
>> the session that I proposed in Neutron has been rejected because it was
>> considered by the PTL as an overlapping work with the Heat goals,
>> therefore I wanted to know if you can to discuss it or I just simple go
>> ahead and start the implementation. I do still believe it can be easily
>> implemented in Neutron and then exposed to Heat but I am really looking
>> forward to having a broader discussion.
>
>I don't think we have any sessions directly related to Neutron, but we are
>definitely interested in discussing this (and other Neutron BPs which may
>have integration points requiring orchestration).
>
>I suggest we have an informal breakout session with those interested on
>Tuesday or Wednesday, or it could be a topic which Steve Baker may
>consider
>for this placeholder session:
>
>http://summit.openstack.org/cfp/details/360
>
>Steve
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev