Hi all,
On 10.07.2017 13:05, Gasparakis, Joseph wrote:
Hi all,
These are the items for this topic:
-What do we have? Where is it? Do we use it? Who owns it?
-Project wide structure and subcomponent structure. (TSC/PTL like)
Trying to kick off the discussion, here are some (scattered) thoughts I
have, please add your thoughts:
*_What do we have? Where is it? Do we use it? Who owns it?_*
Here is a list of what I have seen in my (pretty brief exposure to
OpenContrail)
-Dependencies:
oPackages from Ubuntu or RedHat (about 50 packages)
ohttp://downloads.datastax.com (Cassandra driver + dev package, libuv)
ohttp://ubuntu-cloud.archive.canonical.com (liburcu + dev package)
Plus Kafka (and librdkafka) and Redis for analytics/web ui.
-Repo and build package in https://github.com/Juniper/contrail-vnc (why
called contrail-vnc?) - Pulls from repos
ocontrail-controller
ocontrail-generateDS
ovijava
ocontrail-java-api
ocontrail-vrouter-java-api
ocontrail-vcenter-plugin
ocontrail-build
ocontrail-vrouter
ocontrail-third-party
This fetches a whole bunch of third-party stuff including BIND and DPDK,
and patches most of it.
ocontrail-sandesh
ocontrail-packages
ocontrail-nova-vif-driver
ocontrail-nova-extensions
ocontrail-neutron-plugin
ocontrail-heat
ocontrail-web-controller
ocontrail-web-core
ocontrail-webui-third-party
ocontrail-web-storage
ocontrail-web-server-manager
Plus contrail-dpdk for contrail-vrouter-dpdk.
Is any other github/Juniper project needed?
I do not know who the owners of the above are…
*_Project wide structure and subcomponent structure. (TSC/PTL like)_*
As embarrassing as it might seem, I do not recall what exactly this
refers to… Anybody who attended the OpenContrail reboot Summit?
Wasn't it about deciding which [separable] subprojects the OpenContrail
project should be built of? Each project might have a separate PTL body,
so a committer in web ui isn't necessarily one in contrail-vrouter.
Some thought to kick off the discussion:
- A clear OpenStack separation. This is the top of my personal list. It
should be straightforward to see which bits are generic and which bits
are OSS integration. May require some changes to source code IIRC.
- Each sub-project defines a technology stack and a set of skills needed
for contribute. Roughly, we have REST APIs and config node services
which are mostly Python, control plane services (plus collector and
query engine from analytics) which are C++, and low-level vRouter part,
not to mention Node-based web ui. Maybe it makes sense to manage these
separately, so that someone interested to contribute to e.g. config API
can commit and test their changes with little or no interaction with
control plane services. Makes multiproject features more challenging though.
Best,
Valentine
Thank you in advance,
Joseph
--
Joseph Gasparakis
Intel Corporation
NPG Architecture & Systems Engineering
_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
