Open Stack

On 29/10/13 19:33, Edgar Magana 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 :-)

Well, if you don't manage the dependencies then it won't work. 
Dependencies are not dependencies by definition unless it won't work 
without them. What I think you mean is that you infer the dependencies 
internally to Neutron and don't include them in the artefact that you 
give to the user. Although actually you probably do, it's just not quite 
as explicit.

So it's like Heat, but it only handles networks and the templates are 
harder to read and write.

> 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.

So, to be clear, my interpretation is that in this case you will spit 
out a JSON file to the user in tenantA that says "two networks 
(192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a router 
connecting them" (BTW does "networks" here mean "subnets"?) and a user 
in tenant B loads the JSON file and it creates to *different* networks 
(192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a router 
connecting them in tenantB.

I just want to confirm that, because parts of your preceding paragraph 
could be read as implying that you just open up access to tenant A's 
networks from tenant B, rather than creating new ones.

> 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 think he is absolutely right.

> 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?

I stand by my original analysis that the input part of the API is 
basically just a subset of Heat reimplemented inside Neutron.

As a consumer of the Neutron API, this is something that we really 
wouldn't want to interact with, because it duplicates what we do in a 
different way and that just makes everything difficult for our model.

I strongly recommend that you only implement the output side of the 
proposed API, and that the output be in the format of a Heat template. 
As Clint already pointed out, when combined with the proposed stack 
adopt/abandon features (http://summit.openstack.org/cfp/details/200) 
this will give you a very tidy interface to exactly the functionality 
you want without reinventing half of Heat inside Neutron.

We would definitely love to discuss this stuff with you at the Design 
Summit. So far, however you don't seem to have convinced anybody that 
this does not overlap with Heat. That would appear to forecast a high 
probability of wasted effort were you to embark on implementing the 
blueprint as written before then.

cheers,
Zane.