Hello, I would like to comment a little bit the removal of "Operate a set of servers/labs and services (git, gerrit, jenkins,..)".It may partially work at OPNFV project level but I'm not convinced it's doable everywhere in OPNFV.I would have thought it's up to OPNFV projects to ease the reuse by giving configs for docker build, travis-ci, readthedocs, jjbs, etc... as Functest has done.
Docker automated build allows building any monolithic container but we may suffer from the current design if we publish sliced containers as Functest does.By adding hooks [1], we could bypass that but the notification system doesn't work in case of git tags in such a case.Docker automated build only supports amd64 and then forbids building arm64 containers https://git.opnfv.org/functest/tree/docker/smoke/hooks/post_checkout Travis-ci gives us the flexibility to cross-compile containers to arm64 (or arm32 in case of Raspberry PI) but we will face with the overall timeout due to the Qemu translations.I have also faced with lots of network issues when building my third-parties containers for few anticipation works (OpenStack master, etc...).But it's true that travis-ci is improving and releng is not better regarding that part.I don't see how we could deploy kubernetes or OpenStack quicker than the default timeout as required by functional gates. https://git.opnfv.org/functest/tree/.travis.yml We do care about deploying/testing under nested virtualisation even if it eases the development process.Then performance results won't be relevant (-10%) and then OPNFV will drop the public fair test database which is one of our key benefits.It's even more true for Kubernetes as we would add a virtualisation layer lesser (from a performance point of view) than containers. In case of Functest, we already support lots of external tools and we are offering a way to deploy the full CI/CD (from Jenkins to dashboards) via docker-compose. We are able to publish all artifacts out of OPNFV but we still depend on hardware to ensure Functest is always stable. Or we are forced to setup an external bot running on local resources for fully verifying the changes (I haven't tested that out of gerrit). Cédric Le vendredi 30 novembre 2018 à 11:44 +0000, Frank Brockners via Lists.Opnfv.Org a écrit : > > In the TSC meeting, Manuel voiced a pretty important ask that might > help the discussion moving forward: "Cloud we create a table that > compares OPNFV today with the proposed future", assuming that we'd > evolve along > the path that Bin started to articulate. The table format is to make > things more concrete and could help us in a second step to articulate > where we’d want to focus on moving forward. This includes which > additional work areas we’d like to inspire projects to > work on (or even new projects to be created for). I've tried to > capture the current discussion and proposal into a table below (see > also attached in case groups.io messes up the formatting and color) – > feel free to add/evolve/change per your understanding > – the below is just my reading of Bin’s deck. > > Thoughts? > > Thanks, Frank > > > > > > > OPNFV today > > > Potential Evolution (changes in > blue) > > > > > Design – Outline requirements; Design NFV components and solution > stacks > > > Design – Outline requirements; Design NFV components and solution > stacks; > Focus on cloud native and edge use cases. > > > > > Create – Create new and/or enhance components (most often by working > upstream) to meet the design/requirements > > > Create – Create new and/or enhance components (most often by working > upstream) to meet the design/requirements. > > > > > > Compose – Follow the design and create a running system from a set of > components > > > > Compose – Follow the design and create a running system from a set of > components > > > > > > Deploy – Install and run the composed system on a set of labs > worldwide. This includes enhancement and creation of specific test > and deployment tools (installers, XCI,..). > > > Deploy – Install and run the composed system on a set of labs > worldwide. This includes enhancement and creation of specific test > and deployment tools (installers, XCI,..). > > > > > Test – Test the installation, i.e. running system that represents an > NFV solution stack; as well as test specific aspects of a system. > This includes creation and enhancement of specific > test and deployment tools. In addition, this includes tooling for > verification (OVP/CVP). > > > Test – Test the installation, i.e. running system that represents an > NFV solution stack; as well as test specific aspects of a system. > This includes creation and enhancement of specific > test and deployment tools. In addition, this includes tooling for > verification (OVP/CVP). > > Tool suite: Compose individual tools into a tool suite. > > > > > Iterate/Automate – Create guidelines and tooling for automated > deployment, testing, and test-results reporting. > > > Iterate/Automate – Create guidelines and tooling for automated > deployment, testing, and test-results reporting. > > Create a “DevOps” platform: Tooling to automatically compose the > entire DevOps workflow using cloud services. (Require migration from > DIY hosted labs/git/gerrit/Jenkins to cloud services like packet.net, > github, circleCI, ..) > > > > > Operate – Operate a set of servers/labs and services (git, gerrit, > jenkins,..). Offer Lab-as-a-Service (LaaS). > > > > Operate – > Operate a set of servers/labs and services (git, gerrit, jenkins,..). > Offer Lab-as-a-Service (LaaS). > > > > > > > > > OPNFV Release artifacts: > > Scenarios – installable NFV solution stacks (NFVI); > > “NFVI Platform”Tools (mostly test/operations tools)OVP/CVP solution > > > OPNFV Release artifacts: > > Scenarios – installable NFV solution stacks (NFVI); > > streamlined, i.e. fewer scenarios; increased focus on CN and edge; > “NFVI Platform”Packaged testing/operations tool suiteOVP/CVP > solution“DevOps Platform” > > > > > > > -----Original Message----- > > From: [email protected] <[email protected]> On Behalf > Of Georg Kunz > > Sent: Dienstag, 27. November 2018 18:46 > > To: HU, BIN <[email protected]>; Tim Irnich <[email protected]>; > Trevor Bramwell <[email protected]> > > Cc: AshYoung <[email protected]>; [email protected]; > [email protected]; Manuel Buil <[email protected]> > > Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan > > Hi Bin, > Hi all, > > Due to the lively discussions during today's TSC call, the IRC > minutes are a little light [1]. However, I have to voice my concern > that I cannot agree with the following items: > > [.] > 14:41:31 <bh526r> #info Vote for strategy on Tuesday Dec 4 > 14:42:01 <bh526r> #info Hopefully everyone will agree > 14:43:12 <bh526r> #info We need a decision on Dec 4 in order to > trigger following actions > 14:43:35 <dmcbride> #topic budget discussion > 14:43:45 <bh526r> #info Stalemate is not an option [.] > > I don't understand why "we need a decision by Dec 4 in order to > trigger actions". I seriously appreciate your ambition to move this > forward quickly as the main intention is to strengthen OPNFV's > position. However, I also don't see why > concrete actions are being blocked if there is no decision on Dec 4. > > A core value of open source communities is that those who are > interested in a particular topic, naturally tend to form a group > which jointly works towards a common goal. In our concrete scenario, > we could i) form a devops working group > which works on fleshing out the details of the proposal, and/or ii) > find a group of interested people prototyping some of the "cloud- > based devops methodologies. None of such activities would be > considered a stalemate. The results of such _community-driven_ > activities would help to convince the entire community. A very > successful example in this regard is XCI, which was driven by a small > group of people. > > Certainly, it is the job of all TSC members to actively participate > in the strategy definition and discussion and I urge everybody to do > so. An open source community works best if it is driven by personal > motivation. For sure it does > not work well if deadlines for decisions about unclear directions > are put on a community without a clear understanding why. > > > That said, my current view on the proposal is the following: it > broadens the scope of the community (by a currently undefined > amount), i.e., it adds on top of what we are currently doing. I do > not think that this is the right approach > given shrinking amounts of resources in the community - both in > terms of developers and funding. I believe we need to instead > discuss, as an alternative, if we should and can focus on a very > specific, well-defined and sought-after contribution to the > ecosystem. > I mentioned this in a previous email already: based on input from > stakeholders, I would argue for strengthening the reference platform > (as defined through comprehensive tests) and the corresponding > compliance program. This is my perspective for sure - others > might disagree and I'd love to discuss better proposals. > > [1] > http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2018/opnfv-meeting.2018-11-27-13.54.log.txt > > Best regards > Georg > > -----Original Message----- > From: HU, BIN <[email protected]> > Sent: Tuesday, November 27, 2018 2:22 PM > To: Tim Irnich <[email protected]>; Trevor Bramwell < > [email protected]> > Cc: AshYoung <[email protected]>; Georg Kunz <[email protected]> > ; > [email protected]; > [email protected]; Manuel Buil <[email protected]> > Subject: RE: [opnfv-tsc] Discussion of OPNFV Strategic Plan > > Thank you for pointing out one possibility based on the assumption > that the same resources will do both work. The assumption itself may > not be true because there will be different resources to do different > work in different projects > (which is the reality today). > > So the resource availability is a key factor to consider when we > approve the new projects subsequently after we plan the product > portfolio. When we have dedicated resources to do each job, such > possibility will be unlikely to happen. > > Thanks > Bin > > -----Original Message----- > From: [email protected] <[email protected]> > On Behalf Of Tim Irnich > Sent: Monday, November 26, 2018 11:59 PM > To: HU, BIN <[email protected]>; Trevor Bramwell < > [email protected]> > Cc: AshYoung <[email protected]>; Georg Kunz <[email protected]> > ; > [email protected]; > [email protected]; Manuel Buil <[email protected]> > Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan > > The way I understand Trevor's concern is that if we start spending > more time on packaging tools and supporting their usage downstream, > there will be less time for doing integration work and driving > upstream production readiness. Which > is something I'm concerned about too. > > Pretending that this problem doesn't exist isn't helpful IMHO. > > Tim > > On 11/27/18 2:11 AM, HU, BIN wrote: > > Trevor, > > > > Thank you for you clarifying it. > > > > The integration work is explicitly mentioned to be continued in 3rd > bullet on slide #13 of v0.8. I am attaching it again just in case you > missed it. That work will continue as usual. All related bug fixes > and new features in upstream > will continue as usual too. So I am not sure why it is a concern > here. > > > > Regarding the concern of spending our time to help people use our > tools, isn't it the usual business we are supposed to do today? For > example, after we release Gambia, we are supposed to help people use > it, right? There is a "opnfv-user" > mailing list for this purpose. There isn't much traffic though. It > means either everyone is an expert or no one is interested in using > our release. I wish it was because everyone is an expert, though the > reality might be opposite. > > > > Recently, someone asked me how to run Yardstick on Dovetail. Thanks > Georg for sharing the docs. I was really excited because finally > someone is interested in using our tool. So getting user to use our > tools is exactly what we want, > right? Without users, I don't know how to show others our value, > frankly. > > > > So IMHO, spending our time to help user isn't a concern at all. It > is what we need. And there is no difference of supporting users, e.g. > use OpenStack by OpenStack community, use ODL by ODL community. Etc. > > > > If there is no user to support, we are in trouble because our > deliverables has no value. > > > > Let me know what you think, and if you still have concerns. > > > > Thank you > > Bin > > > > -----Original Message----- > > From: [email protected] <[email protected]> > On Behalf > > Of Trevor Bramwell > > Sent: Monday, November 26, 2018 4:54 PM > > To: HU, BIN <[email protected]> > > Cc: Tim Irnich <[email protected]>; AshYoung <[email protected]>; > > > Georg Kunz <[email protected]>; Manuel Buil <[email protected]>; > > > [email protected]; > [email protected] > > Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan > > > > Hi Bin, > > > > Perhaps 'integrated' is a better word here than 'supported'. A lot > of the work in OPNFV involves integrating many of these upstream > components which in turn exposes bugs, or creates features that > enable an NFV use case. > > > > I'm quite terrible with examples, but I'm sure others from the > community have time. > > > > Regards, > > Trevor Bramwell > > > > On Tue, Nov 27, 2018 at 12:26:33AM +0000, HU, BIN wrote: > >> Trevor, > >> > >> Thank you for your question. > >> > >> Can you give more details and examples of "doing what we're best > at, which is getting NFV supported by upstream projects."? > >> > >> Thank you > >> Bin > >> > >> -----Original Message----- > >> From: Trevor Bramwell <[email protected]> > >> Sent: Monday, November 26, 2018 4:17 PM > >> To: HU, BIN <[email protected]> > >> Cc: Tim Irnich <[email protected]>; AshYoung <[email protected]>; > > >> Georg Kunz <[email protected]>; Manuel Buil <[email protected]> > ; > > >> [email protected]; > [email protected] > >> Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan > >> > >> Hi Bin, > >> > >> I'm still unclear on the first point: "Enabling and automating > stakeholders' business transformation into DevOps organization" > >> > >> From what I've read it seems like the suggestion is to package up > everything that makes up OPNFV (Platform, CI/CD piplines, testing / > verification / certification tools, etc.) and turn that into > something that can be deployed by a > company internally. > >> > >> Is that what is being suggested here, or something else? And if so > I'd be concerned that we'd actually be reducing companies incentive > to be involved, or more of our time would be spent trying to support > people using the tool then > doing what we're best at, which is getting NFV supported by upstream > projects. > >> > >> Regards, > >> Trevor Bramwell > >> > >> On Mon, Nov 26, 2018 at 09:04:57PM +0000, HU, BIN wrote: > >>> Tim, > >>> > >>> Not sure if you get a chance to follow the most recent > discussion. > >>> > >>> The ask is merely to agree on a strategy (i.e. the vision and > direction) outlined on Slide #13, supported by the steps of actions > summarized on slide #16. See attached the most recent update v0.8. > >>> > >>> Please let me know if there is anything unclear here. > >>> > >>> Thanks > >>> Bin > >>> > >>> -----Original Message----- > >>> From: [email protected] <[email protected]> > On > >>> Behalf Of Tim Irnich > >>> Sent: Monday, November 26, 2018 12:57 PM > >>> To: HU, BIN <[email protected]>; AshYoung <[email protected]>; > Georg > >>> Kunz <[email protected]>; Manuel Buil <[email protected]> > >>> Cc: > [email protected]; > [email protected] > >>> Subject: Re: [opnfv-tsc] Discussion of OPNFV Strategic Plan > >>> > >>> On 11/26/18 4:40 PM, HU, BIN wrote: > >>>> > >>>> If I understand correctly, Point #1 and #3 are actually the same > question, i.e. what will we do in the next step? > >>> > >>> No, I'm rather suggesting to make sure our understanding is > complete before we proceed. We clearly do not yet sufficiently > understand what exactly the decision is you're asking us to take, so > we cannot proceed. > >>> Let's continue to work on this until we have the required > clarity, and then decide. > >>> > >>> Regards, Tim > >>> > >> > >> > >>> -=-=-=-=-=-=-=-=-=-=-=- > >>> Links: You receive all messages sent to this group. > >>> > >>> View/Reply Online (#4856): > >>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opnfv.org > >>> _g_opnfv-2Dtsc_message_4856&d=DwIF-g&c=LFYZ- > o9_HUMeMTSQicvjIg&r=6qPc > >>> DOqMgwf1K_r6YIIHhw&m=MsGFeXeJn1GRo- > GvLejVXrmPgRHvZKjmVkiBKZgaQdc&s=j > >>> 9hLZ3q9g0pHbtq-b6cZkh4PaKLsKtMkaWRRHHHAcqQ&e= > >>> Mute This Topic: > >>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opnfv.org > >>> _mt_27802341_557206&d=DwIF-g&c=LFYZ- > o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf1 > >>> K_r6YIIHhw&m=MsGFeXeJn1GRo-GvLejVXrmPgRHvZKjmVkiBKZgaQdc&s=fTo_- > Z8GU > >>> Aaz9sCAJyClb_m_LGWxF3_23Siiy8SJdtY&e= > >>> Group Owner: > [email protected] > >>> Unsubscribe: > >>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opnfv.org > >>> _g_opnfv-2Dtsc_unsub&d=DwIF-g&c=LFYZ- > o9_HUMeMTSQicvjIg&r=6qPcDOqMgwf > >>> 1K_r6YIIHhw&m=MsGFeXeJn1GRo- > GvLejVXrmPgRHvZKjmVkiBKZgaQdc&s=f8xgHpaw > >>> JHb8E2ELrIpuKGYOIZmFHT6fOJf7huGMVHM&e= > >>> [[email protected]] > >>> -=-=-=-=-=-=-=-=-=-=-=- > >> > > -- > Dr.-Ing. Tim Irnich, Senior Program Manager Developer Engagement > E-Mail: [email protected] > Mobile: +49 172 2791829 > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham > Norton, HRB 21284 (AG Nürnberg) > > > > > -=-=-=-=-=-=-=-=-=-=-=-Links: You receive all messages sent to this > group. > View/Reply Online (#22474): > https://lists.opnfv.org/g/opnfv-tech-discuss/message/22474 > Mute This Topic: https://lists.opnfv.org/mt/28277855/1217365 > Group Owner: [email protected] > Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [oll > [email protected]]-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22501): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22501 Mute This Topic: https://lists.opnfv.org/mt/28277855/21656 Group Owner: [email protected] Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
