Hi,
In addition to the classical river names, Functest Kubernetes now delivers
Docker tags per Kubernetes release.
(Thank you for all the feedbacks, especially the last one from OOM PTL which
convinced me to prioritize this idea)
The new tags simply match all Kubernetes versions from v1.13 :
Hi,
I just published "Run CNTT Kubernetes Based Reference Conformance" as Katacoda
scenario in the Xtesting series.
It allows everybody to deploy Kubernetes and then to run a subset of CNTT RC2
from your browser in ~20 minutes.
It's worth mentioning that you can click on all instructions to
Hi,
I would have empathized that Functest Jerma is already part of CNT Baraque.
Yes, we could say it’s self-released or it’s supporting CNTT release management
(why should we create a 6 month gap if useless?).
Speaking CNTT alignment without listing Functest seems falsy.
Functest (and Xtesting)
Hi Lincoln,
My point about OVP is neither its name or its business.
I was simply asking for some clarity about “OVP engagement plan” in MELD topics.
Agree, CNTT RC1 and RC2 document and select test cases
implemented/integrated/maintained by OPNFV.
Merging CNTT and OPNFV doesn’t change the
Jim,
Yes O in OVP is deprecated and falsy for a while (see Compliance and
Verification Committee – LFN Committee). Nothing related to Meld.
Sorry, I still don’t understand “OVP engagement plan” out of the rename already
on the agenda.
BYW I would consider that any CNTT RC2 super-set (Cloud
Hi,
In "Task Force Scope Statements", I franky don't understand "OVP engagement
plan".
CNTT RC1 and RC2 describe and select all mandatory test cases from OPNFV and
even define the way to export the test results (99,999% of the overall work).
In that case, OVP is reduced to a reviewer committee
Hi,
I share a couple of Functest and CNTT RC2 proposals which should help any new
comers to contribute to the CNTT implementation part, key to our success.
https://www.linkedin.com/pulse/call-functest-cntt-rc2-contributions-c%C3%A9dric-ollivier/
Kubernetes Conformance aims to provide an high
Hi,
It seems that you correctly configured EXTERNAL_NETWORK=floating_net
(the autodiscovery may fail if multiple external networks and if a few of them
are unreachable from jumphost)
As far as I can see, the VMs is up and received its IP via DHCP as expected.
I would have double checked that
Al,
I would encourage us to stop mentioning "Debt" everywhere.
It's quite disrespectful from the main (past and present) contributors and
their companies.
Even more when it may come from external people (see FMO) who don't contribute
code to the project and who somehow are unaware of the open
; Jim Baker
Cc : David McBride ; Alec Hothan (ahothan)
; Georg Kunz ; Al Morton
; opnfv-tech-discuss
; opnfv-project-leads
; opnfv-...@lists.opnfv.org
Objet : Re: [opnfv-tsc] Jerma Release Meeting: Requirements Working Group
Cedric,
On 8/19/20 2:54 AM, cedric.ollivier via lists.opnfv.org
Hi Jim,
Sorry I don’t understand the logic hidden in the questions (especially your
last question).
Maybe the following technical details may help us.
All amd64, arm and arm64 jerma docker tags (functest, xtesting and
functest-kubernetes) are rolling vs our stable/jerma branches.
We could
Hi,
Functest Jerma has been released 10/14/19.
https://lists.opnfv.org/g/opnfv-tsc/message/5636
Functest has already been updated to take CNTT Baraque requirements into
account.
Of course Functest will be continuously synced with RA1 via all RA1 meetings if
any API capability switches to
Hi,
I think they are a couple of very different scenarios and the dynamic hardware
allocation doesn't fit all.
- deliverables builds and code verification (unit tests, linters, etc.)
- installer gates (OpenStack/K8s deployment and its testing)
- test framework gates
Hi,
What does "reimagine" mean here ?
Is it a new fourth option because it doesn't seem compatible at first glance
with the merger option already introduced to the LFN Board.
OPNFV has always tried to solve the NFV issues from day 0 and even the charter
and website were updated to please CNTT
-1
I don’t think 1988 is correct here.
And I thought Linux Foundation was built around Kernel quite as old as IRC
(possibly older when our IETF experts would verify your proposal).
What’s your point here ? and even worse why so much highlights (e.g. upper
case) if it simply works ?
I would
Hi,
The repo has worked very well since we built our own repo as highlighted by
Functest gates .
Please see below the last runs:
https://build.opnfv.org/ci/job/functest-opnfv-functest-vnf-hunter-cloudify_ims-run/370/console
Hi,
Be free to run Functest K8s Jerma vs Kubernetes 1.17
https://wiki.opnfv.org/pages/viewpage.action?pageId=44892422
Cédric
De : Chandrasekaran Ramachandran [mailto:chandrasekara...@hcl.com]
Envoyé : lundi 18 mai 2020 09:01
À : OLLIVIER Cédric TGI/OLN
Cc : Sangeetha K.R; Anusha N;
Hi Parker,
Thank you for your contributions and I was pleased to discuss with you in the
LFN events.
Have fun in your next activities.
I would emphasize that you seem currently top3 in the opensource table only
counting commits and gerrit reviews.
2020+Active+Contributors rather give credits
Hi,
Functest K8s deals with API. Then It works whatever you deploy K8s in
OpenStack or not.
For your information, we deploy K8s on baremetal in our gates.
Here it seems you didn't run the right container (you pulled right one but
executed the OpenStack one instead)
Your container shouldn't
Hi,
Functest Kali is out !
It allows verifying OpenStack Ussuri which is being released and Kubernetes
v1.18.
The marketing messages always announce product-ready and easy-to-use software.
But it's so true for Functest !
The full CI chains are still deployed in a few commands and it's so
Hello,
Functest team proudly announces the publication of Functest Jerma containers.
They allow verifying Kubernetes v1.16.1 and the next OpenStack Train which
should be released in the next days.
https://releases.openstack.org/train/schedule.html
Functest is more than ever a collection of
David,
In Spain ?
I may be wrong here but I don’t think the distance between Serbia or Bulgaria
and Spain is about 72 km (mentioned in the wikipedia link).
Cédric
De : opnfv-...@lists.opnfv.org [mailto:opnfv-...@lists.opnfv.org] De la part de
David McBride
Envoyé : mardi 17 septembre 2019
Hello,
I would like to nominate Juha Kosonen (Nokia) for Testing.
He fully deserves that award regarding his constant and key contributions to
Functest releases.
Juha has always driven our Rally-based testcases in the best ways and a huge
part of his contributions is upstream conforming to our
Hi Alec,
Several upstream projects such as tempest should run vs master.
But for instance, we have to disable RefStack when switching to OpenStack
Queens as it’s currently linked to testr (what about master?).
I’m not sure we can introduce all new testcases in master and then we may
develop in
Hello Morgan,
Would it be possible to switch to OPNFV Functest latest containers (several
runs) ?
We have updated all OPNFV Functest test cases for Gambia Release (N+1) and we
need a reference (and stable) platform to get a real overview.
From the time being, only Compass is currently
Hello Morgan,
Thank you very much for your help.
All tests done via ONAP OpenLab has been very helpful throughout the F-release
by providing the quickest feedbacks.
We are checking if Functest testcases have to complete Snaps’ garbage
collectors for floating ips.
That would explain this
Hello,
Functest team proudly announces the first publication of Xtesting.
Xtesting have leveraged on Functest efforts started from Euphrates
(python framework, docker slicing, dependency management, etc.) to
provide a reference testing framework allowing SDN/NFV testing on any
type of
No, “blocking innovation” was simply related to a possible inability to change
our internal methods (timethis()) which are out of our Framework.
You highlighted a real problem: we need to remove obsolete utils which don’t
meet our criteria and may be possibly reused by others.
Cleaning our tree
Yes, the “issue” is simply related that we all leverage on git master instead
of released packages (see OpenStack Requirements’ upper-constraints) during the
development cycle.
More, this case is a little bit more complex as this function shouldn’t be
considered as part of our framework and we
Hello Manuel,
In case of Functest, we are simply improving our code that why we are removing
uncovered obsolete (and unused internally) functions.
As we take care of pylint output and coverage, we should stop maintaining
modules/functions which are out of our standards and unused by Functest.
It seems a run-time dependency as your shell script calls it.
My understanding is that test-requirements.txt should mainly include unit tests
requirements.
It is synchronized with OpenStack Pike's global requirements then you should
add the lower bound as well.
Listing upper-constraints doesn’t mean that it will be installed. It only
enforces the right version.
Functest doesn’t leverage on it then why should we force the installation in
our container?
It must be installed as any parser dependency when installing your package.
I can modify your
Hello,
It should have been added as dependency (requirements.txt) in your python
package.
I don’t want to list it in the Dockerfile to bypass your issue.
Cédric
De : opnfv-tech-discuss-boun...@lists.opnfv.org
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] De la part de
I will update the presentation Docker Slicing shown in a previous testing group
meeting to add a section about manifests.
We will organize a phone call if required later.
Cédric
Beierl, Mark a écrit
Thanks, Cédric
Unfortunately I will not be at the Plugfest, so if you do a session,
Hello,
Functest containers already leverage on Docker manifests. It's part of our
docker refactoring which included slicing, manifests, releng multijobs...
I will introduce it next week if you're interested in and the changes required.
Cédric
Beierl, Mark a écrit
Hello,
Here is an
+1
My only concern is to get the same capabilities via RELENG than the Docker
Automated tools or Travis-ci.
https://lists.opnfv.org/pipermail/opnfv-tech-discuss/2017-October/018536.html
But we are working on that point :
https://gerrit.opnfv.org/gerrit/#/c/46111/
Cédric
De :
Hello Alec,
Our Functest containers are not built by releng (we are still waiting for
updates).
I have configured docker automated build settings to build latest, euphrates,
stable and opnfv-X.Y.Z tags.
Please see previous mail threads on Docker automated builds or travis-ci for
more
Hello,
I fully support too.
For a)
It should be noted that we have developed lots of unit tests to fully cover our
Framework (the global coverage is quite good too).
We are checking our code via PEP8 [1] and Pylint [2] to increase continuously
the code quality.
For instance, Framework must be
Alex,
Yes. You know I was waiting for tests from your side. As manifest works as
expected, we can remove most of them.
But I will keep the one to build/publish containers in any repo as it's very
useful.
My sentence was focused on Functest.
Cédric
Alexandru Avadanii a écrit
Hi,
Hello Franck,
The basic test suite is hardcoded for keystone v2 (and other limitations) what
becomes an issue.
We must sync with ODL test community regarding that point if it makes sense to
continue on updating this suite.
Yes our config file already allows defining multiple ODL testcases
Hello,
I understand your point but Functest requires a default answer to finish the
containers and to write the testcase config file (suites and dependencies on
scenarii or installers).
Then we take the decision about the release (the last one seems fine) and if
the NetVirt test suite is ran
Hello,
It’s true if we only consider the Neutron API but we run several dedicated
tests to check the ODL Neutron API.
Even if the default robot suite is quite basic, we have to know which branch of
ODL we should clone.
I know that it shouldn’t induce problems because the API has not been
42 matches
Mail list logo
