Hi Nabeel I was thinking about putting the initial version up on Amazon for now. Hardware budgets require fairly extensive negotiations. However if anybody has an externally accessible openstack cluster and about 10 TB of storage space. We can put up the system there. Any volunteers with ready made public lab space?
Thanks Greg From: Nabeel Asim <na...@techtrueup.com> Date: Friday, July 7, 2017 at 5:12 AM To: Gregory Elkinbard <gelkinb...@juniper.net>, 'Filip Pytloun' <fpytl...@mirantis.com> Cc: "dev@lists.opencontrail.org" <dev@lists.opencontrail.org>, 'Alexandre Levine' <alexandrelev...@gmail.com> Subject: RE: [opencontrail-dev] [TCS] [Infra] OpenContrail CI requirements Thanks Gregory for the detailed insight. Opening it up will make things much better as we have come across this issue many a times where things fail and we are not able to debug. Do we have a target lab identified to set up external version of the CI or the same setup will be used? Regards, Nabeel From: Dev [mailto:dev-boun...@lists.opencontrail.org] On Behalf Of Gregory Elkinbard Sent: Thursday, July 6, 2017 7:07 PM To: Filip Pytloun <fpytl...@mirantis.com> Cc: dev@lists.opencontrail.org; Alexandre Levine <alexandrelev...@gmail.com> Subject: Re: [opencontrail-dev] [TCS] [Infra] OpenContrail CI requirements Hi Filip, We may have to separate the documents into a requirements document and a design document. Design document would have all you describe. However we are in a bit of a chicken and egg situation. I was hopping that we can piggy back a bit on the existing CI system which is currently largely behind the FW. It is functional, but I suspect it is lacking the level of design documentation you mention bellow. Let me describe what exists right now as far as I understand it. Current CI system is based around Zuul and Jenkins Zuul watches for events from Gerrit and triggers on-demand builds via Jenkins. Jenkins build Contrail and OpenStack, pulls in some 3rd party packages. Then packages Contrail bits into a series of fat (role based) containers (Alex has a separate proposal on improving this). Which can then be tested by deploying a single instance OpenStack and Contrail in a VM and running some basic tests. While the results are publicly visible, it is hard for anybody outside the firewall to debug because artifacts and test VMs are not accessible to external users. Don’t know what unit testing exists as part of the build process, need to ask. I saw some components on the GitHub have tests in the tree, but it is not universal. May be we can come up with a MVP set of requirements and ask for Juniper eng to set up an external version of their CI modified to address initial community needs. After that CI becomes a community project, where further improvements (including documentation) would be driven by the community effort. I thought that for initial set of requirements we can start with these. 1. Ability to trigger builds from Gerrit reviews 2. Ability to do nightly’s and other scheduled builds 3. Ability to do release builds 4. Ability for external users to have occasional access to CI test VMs for debugging purposes (similar to OPNFV way of doing things, you ask infra group for temp access) Can you think of any other requirements which should be there. Thanks Greg On Jul 6, 2017, at 2:22 AM, Filip Pytloun <fpytl...@mirantis.com<mailto:fpytl...@mirantis.com>> wrote: Hello, I am glad that things about opencontrail community are moving forward.. I am mostly interested in packaging (as a Debian Maintainer) so I guess I can help here a little. Some thoughts about what should such document describe (according to some "missing pieces" that people are asking about): - components and their individual testing (eg. unit tests of vrouter, controller, python tests, etc.) - infrastructural, cross-component testing (using Fabric tooling) - build process and cross-component dependencies (as it's kind-of spaghetti, scons, generation of python code, etc.) - it also includes way how to get all the source code, eg. contrail-vnc or maybe better tooling that we are using [1] - packages build (Debian + RHEL), contrail-packages vs. contrail-packaging - build and maintanence of 3rd party dependencies (we know this is and always was a mess) - eg. kafka, some python- modules, etc. - this is something that needs to get better, resp. we already did it at tcpcloud/Mirantis so we can help here [2] by providing pipelines and flow to build and maintain these packages - bundled 3rd party dependencies (bind, etc.) with extra patches which is very dirty and should not exist at all - these extra dependencies should be also maintained as separate distribution packages - branching and releasing - this was always a mess, not communicated at all, almost no one knows what branch is stable, development, which one to use for production and how they are maintained That are my initial inputs, I think we can gather more. Filip --- [1] https://github.com/Mirantis/contrail-pipeline [2] https://github.com/tcpcloud?utf8=%E2%9C%93&q=debian-&type=&language= On 2017/07/06 01:30, Gregory Elkinbard wrote: Hi folks, Looking to put together a requirements doc for the community CI. Volunteers to own the doc? Please provide requirements inputs to the list, while the docs repo is being created. Thanks Greg _______________________________________________ Dev mailing list Dev@lists.opencontrail.org<mailto: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
