Hi Gregory,
On 07.07.2017 22:26, Gregory Elkinbard wrote:
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?
What are the requirements other than storage, I mean, in terms of CPUs
and memory?
Valentine
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
_______________________________________________
Dev mailing list
Dev@lists.opencontrail.org
http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
