Open Stack

Zen, Kevin, Aaron, Salvatore et al,

Thank you so much for taking some time and reviewing this proposal. I
couldn't get any time slot neither in Neutron nor Heat track to have a deep
discussion about this proposal. My conclusions are the following:

- This API should be allocated in Heat project, at least will start there
and see how the implementation goes. I am new in Heat, so I will need some
help  :-)
- There are a lot of people who find it interested and useful, therefore It
should be implemented.
- It should be extended to all new "advanced services" (VPNaaS, FWaaS,
LBaaS)
- Dependencies should be included, my point here is to let tenants to
do/control that, even if they make mistakes, is there network design after
all.
- Horizon support will bring a lot of visibility, I will prepare some
mock-ups.

Open Questions:
Is there enough interest in order to schedule an "unconference" session?
 (don't want to be the only one in the room)
What would happen with the concept of "Services Insertion in Neutron"?
Should it be also move to Heat?


Thanks again everybody and I will see you in just one more day.

Edgar



On Sat, Nov 2, 2013 at 1:12 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> Hi.
>
> I looked at the detailed API specification submitted by Edgar.
> I think that the document Edgar shared does a fine job in discussion how
> an API for managing logical topologies should work.
> On the other hand, there are two aspects which still need some
> clarification, and which perhaps are at the source of the confusion
> regarding whether it belongs to neutron, heat, or anywhere else.
>
> First, the "use cases" section merely re-states the objective session. I
> think that section should somehow address the questions "why do we need
> this API?" "How having an API for storing network topologies would be
> useful for us".
>
> The other aspect is that - and I might be terribly wrong here - I think
> that one of the goals Neutron API was already supposed to abstract the
> complexity of network topologies - if we need another API (or perhaps more
> aptly an extension of the Neutron API) to satisfy this goal, does this mean
> the Neutron API is failing in one of its main goals?
>
> Finally it would be interesting to have a few more details concerning how
> topologies created with this new API would be reflected on the existing
> data model. While this appears easy for bridges and routers, it is not
> immediate for other 'nfds' such as dhcp services.
>
> Salvatore
>
>
> On 29 October 2013 19:48, Aaron Rosen <arosen at nicira.com> wrote:
>
>> Hi Edgar,
>>
>> I definitely see the usecase for the idea that you propose. In my
>> opinion, I don't see the reason for moving the management of topology into
>> neutron,  Heat already provides this functionality (besides for the part of
>> taking an existing deployment and generating a template file). Also, I
>> wanted to point out that in a way you will have to do orchestration as
>> you're topology manager will have to call the neutron api in order to
>> create the topology and tear it down.
>>
>> Best,
>>
>> Aaron
>>
>>
>> On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana <emagana at plumgrid.com>wrote:
>>
>>> Tim,
>>>
>>> You statement "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"
>>> Is exactly what we are proposing, and this is why we believe this is not
>>> under Heat domain.
>>>
>>> This is why we are NOT proposing to manage any dependency between network
>>> elements, that part is what I call "intelligence" of the orchestration
>>> and
>>> we are not proposing any orchestration system, you are already have that
>>> in place :-)
>>>
>>> So, we simple want an API that tenats may use to "save", "retrieve" and
>>> "share" topologies. For instance, tenant A creates a topology with two
>>> networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and
>>> a
>>> router connecting them. So, we first create it using CLI commands or
>>> Horizon and then we call the API to save the topology for that tenant,
>>> that topology can be also share  between tenants if the owner wanted to
>>> do
>>> that, the same concept that we have in Neutron for "share networks", So
>>> Tenant B or any other Tenants, don't need to re-create the whole
>>> topology,
>>> just "open" the shared topology from tenant A. Obviously, overlapping IPs
>>> will be a "must" requirement.
>>>
>>> I am including in this thread to Mark McClain who is the Neutron PTL and
>>> the main guy expressing concerns in not  having overlapping
>>> functionalities between Neutron and Heat or any other project.
>>>
>>> I am absolutely, happy to discuss further with you but if you are ok with
>>> this approach we could start the development in Neutron umbrella, final
>>> thoughts?
>>>
>>> Thanks,
>>>
>>> Edgar
>>>
>>> On 10/29/13 8:23 AM, "Tim Schnell" <tim.schnell at RACKSPACE.COM> wrote:
>>>
>>> >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-insertio
>>> >>>n
>>> >>>-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
>>> >
>>> >
>>> >_______________________________________________
>>> >OpenStack-dev mailing list
>>> >OpenStack-dev at lists.openstack.org
>>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131102/4a8288ab/attachment.html>