Hi Cédric, is there a way to have a per-scenario functest config file? We could have a default file, which we’d modify on a case by case basis. Note that e.g. only a subset of the scenarios use NetVirt, hence having Netvirt as a default testsuite probably won’t make sense.
Thanks, Frank From: cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com] Sent: Dienstag, 8. August 2017 11:17 To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; RICHOMME Morgan IMT/OLN <morgan.richo...@orange.com>; Tim Rozet <tro...@redhat.com>; narinder.gu...@canonical.com; 'Michal Skalski' <mskal...@mirantis.com>; Chigang (Justin) <chig...@huawei.com>; hu.zhiji...@zte.com.cn; David McBride <dmcbr...@linuxfoundation.org>; Georg Kunz <georg.k...@ericsson.com>; Tim Irnich <tim.irn...@ericsson.com>; Manuel Buil <manuel.b...@ericsson.com>; Michael Polenchuk <mpolenc...@mirantis.com>; HE Ruan IMT/OLS <ruan...@orange.com>; Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco) <jlin...@cisco.com>; Feng Pan <f...@redhat.com>; Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) <mcmar...@cisco.com> Cc: wangwulin <wangwu...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org Subject: RE: [OPNFV] ODL target Release for Euphrates 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 by default before the possible harmonization. I would have thought it was an upper decision as for OpenStack. Cédric De : Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com] Envoyé : mardi 8 août 2017 10:10 À : RICHOMME Morgan IMT/OLN; Tim Rozet; narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal Skalski'; Chigang (Justin); hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride; Georg Kunz; Tim Irnich; Manuel Buil; Michael Polenchuk; HE Ruan IMT/OLS; Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at Cisco); Feng Pan; Michal Cmarada -X (mcmarada - PANTHEON TECHNOLOGIES at Cisco) Cc : OLLIVIER Cédric IMT/OLN; wangwulin; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> Objet : RE: [OPNFV] ODL target Release for Euphrates Hi Morgan, it might well be that there is no one answer to your question – especially for those scenarios which are leading edge and actively drive development upstream (i.e. in ODL and HoneyComb). In addition, given the sister relationship between ODL and Honeycomb, model updates go hand in hand – which drive another version dependency. For FDS, we plan for an effort similar to what we’ve done for Danube: Once we’re getting closer to the E-release, we’ll try to harmonize on a single version of ODL, i.e. we’ll try to harmonize on a pre-release version of Nitrogen – but for the time being, you’ll find different scenarios using different versions of ODL (sometimes even dedicated builds, e.g. as used for the GBP-Netvirt PoC or for the fdio-dvr scenario), also due to the fact that Karaf-4 migration isn’t yet done for all the components. Regards, Frank From: morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> [mailto:morgan.richo...@orange.com] Sent: Dienstag, 8. August 2017 09:18 To: Tim Rozet <tro...@redhat.com<mailto:tro...@redhat.com>>; narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal Skalski' <mskal...@mirantis.com<mailto:mskal...@mirantis.com>>; Chigang (Justin) <chig...@huawei.com<mailto:chig...@huawei.com>>; hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride <dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>; Georg Kunz <georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>; Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; Tim Irnich <tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>; Manuel Buil <manuel.b...@ericsson.com<mailto:manuel.b...@ericsson.com>>; Michael Polenchuk <mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com>>; HE Ruan IMT/OLPS <ruan...@orange.com<mailto:ruan...@orange.com>>; Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>> Cc: OLLIVIER Cédric IMT/OLN <cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>; wangwulin <wangwu...@huawei.com<mailto:wangwu...@huawei.com>>; opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org> Subject: [OPNFV] ODL target Release for Euphrates Hi, I did not find the list of the target versions for the main components integrated in Euphrates version. it would make sense to explicitely reference them on one of the wiki pages dedicated to the release https://wiki.opnfv.org/display/SWREL/Euphrates In functest, we need to know it. Cedric consolidated Functest in order to manage properly the upstream dependencies (including clients/tooling/lib needed for testing relatively to upstream components) and introduced a clean packetization, which is key for an integration project. At the moment, the only ODL version reference we found was beryllium-sr4, which is pretty old. According to https://wiki.opnfv.org/display/SWREL/Euphrates+Scenario+Status scenario owners dealing with ODL are: - Frank (Apex ∩ Fdio) - Tim Inrich (Apex ∩ bgpvpn) - Brady (not sure the page is up to date....) / Manuel (Apex ∩ Sfc) - Georg (not sure it is up to date....) Apex ∩ gluon - Tim Rozet (Other Apex scenarios) - Ruan He (Compass ∩ moon) - Justin (Other Compass scenarios) - Zhiang (Daisy ∩ moon) - Michael (Fuel/MCP) could you confirm the target version for ODL? /Morgan note: no scenario ODL with joid referenced in the page. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
