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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
