Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.
I guess we can assist with this one. We have the HW needed and a ci environment. We will be happy to do so. I need some help to understand the needed in order integrate into os ci. Who can assist with that? Itai Sent from my iPhone On Nov 16, 2014, at 3:31 PM, Irena Berezovsky ire...@mellanox.com wrote: Hi Steve, Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal node with Mellanox SR-IOV NIC. This job is reporting on neutron patches. Currently API tests are executed. The contact person for SRIOV CI job is listed at driverlog: https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439 The following items are in progress: - SR-IOV functional testing - Reporting CI job on nova patches - Multi-node setup It worth to mention that we want to start the collaboration on SR-IOV testing effort as part of the pci pass-through subteam activity. Please join the weekly meeting if you want to collaborate or have some inputs: https://wiki.openstack.org/wiki/Meetings/Passthrough BR, Irena -Original Message- From: Steve Gordon [mailto:sgor...@redhat.com] Sent: Wednesday, November 12, 2014 9:11 PM To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells); Irena Berezovsky; ba...@cisco.com Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List (not for usage questions) Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other features that can't be tested on current infra. Hi all, We had some discussions last week - particularly in the Nova NFV design session [1] - on the subject of ensuring that telecommunications and NFV-related functionality has adequate continuous integration testing. In particular the focus here is on functionality that can't easily be tested on the public clouds that back the gate, including: - NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device locality) - SR-IOV with Intel, Cisco, and Mellanox devices (possibly others) In each case we need to confirm where we are at, and the plan going forward, with regards to having: 1) Hardware to run the CI on. 2) Tests that actively exercise the functionality (if not already in existence). 3) Point person for each setup to maintain it and report into the third-party meeting [2]. 4) Getting the jobs operational and reporting [3][4][5][6]. In the Nova session we discussed a goal of having the hardware by K-1 (Dec 18) and having it reporting at least periodically by K-2 (Feb 5). I'm not sure if similar discussions occurred on the Neutron side of the design summit. SR-IOV == Adrian and Irena mentioned they were already in the process of getting up to speed with third party CI for their respective SR-IOV configurations. Robert are you attempting similar with regards to Cisco devices? What is the status of each of these efforts versus the four items I lifted above and what do you need assistance with? NUMA We still need to identify some hardware to run third party CI for the NUMA-related work, and no doubt other things that will come up. It's expected that this will be an interim solution until OPNFV resources can be used (note cdub jokingly replied 1-2 years when asked for a rough estimate - I mention this because based on a later discussion some people took this as a serious estimate). Ian did you have any luck kicking this off? Russell and I are also endeavouring to see what we can do on our side w.r.t. this short term approach - in particular if you find hardware we still need to find an owner to actually setup and manage it as discussed. In theory to get started we need a physical multi-socket box and a virtual machine somewhere on the same network to handle job control etc. I believe the tests themselves can be run in VMs (just not those exposed by existing public clouds) assuming a recent Libvirt and an appropriately crafted Libvirt XML that ensures the VM gets a multi-socket topology etc. (we can assist with this). Thanks, Steve [1] https://etherpad.openstack.org/p/kilo-nova-nfv [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty [3] http://ci.openstack.org/third_party.html [4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/ [5] http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/ [6] http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [NFV] NFV sub group meeting week of November 10th
Team, Do we meet Wednesday or Thursday this week? Best, Itai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Meeting today ? 22nd October
Hi all, Do we have a meeting today? I can't see something in the wiki about today... Itai Sent from my iPhone On Oct 8, 2014, at 2:06 AM, Steve Gordon sgor...@redhat.com wrote: Hi all, Just a quick reminder that the NFV subteam meets Wednesday 8th October 2014 @ 1400 UTC in #openstack-meeting-alt on FreeNode. I have started putting an agenda together here, feel free to add: https://etherpad.openstack.org/p/nfv-meeting-agenda Also many thanks to Itai for running the meeting for me last week. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] ETSI NFV gap analysis [NFV]
Team, Following my action item from last week IRC. It seems that the document is ready for submission by ETSI NFV team. It was written in a liaison form as this is how they are used to operate. They are wondering who should they send it to... IMHO it seems a good idea that the NFV sub group will receive it in behalf of the community. Thoughts? Itai Sent from my iPhone ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] NFV Meetings
Hi, Was looking at the wrong channel last week…. Looked at the minutes. Tnx for raising the topic. Let’s discuss this week. Tnx! I On 9/8/14, 5:49 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, Hope you are doing good. Did we have a meeting last week? I was under the impression it¹s was scheduled to Thursday (as in the wiki) but found other meetings in the IRCŠ What am I missing? Do we have one this week? Hi Itai, Yes there was a meeting last Thursday IN #openstack-meeting @ 1600 UTC, the minutes are here: http://eavesdrop.openstack.org/meetings/nfv/2014/nfv.2014-09-04-16.00.log. html This week's meeting will be on Wednesday at 1400 UTC in #openstack-meeting-alt. Also, I sent a mail about the sub groups goals as we agreed ten days ago. Did you see it? Happy to hear your thoughts. I did see this and thought it was a great attempt to re-frame the discussion (I think I said as much in the meeting). I'm personally still mulling over my own thoughts on the matter and how to respond. Maybe we will have more opportunity to discuss this week? Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] NFV Meetings
Hi, Hope you are doing good. Did we have a meeting last week? I was under the impression it¹s was scheduled to Thursday (as in the wiki) but found other meetings in the IRCŠ What am I missing? Do we have one this week? Also, I sent a mail about the sub groups goals as we agreed ten days ago. Did you see it? Happy to hear your thoughts. Itai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [NFV] NFV sub group - How to improve our message and obtain our goals better
Following last week IRC, please find below a suggestion to improve the description and the messaging to the wider community about NFV. I think this group is a great initiative and very important to explain NFV to the wider developers community of OpenStack. While NFV is becoming a more known term for the community (a new and good thing!) I feel there is still a gap in explaining why it needs special care. Or maybe more precise, do we want to claim it needs special care? I would claim we shouldn’t think about it as “special” but as a great use case for OS with some fine tune needs that are relevant (in most) to other cases too. So in our wiki we have few great starts. * We have the HL description of ETSI NFV use case * We have the workloads types definition * We have the great section by Calum about two specific apps What we might consider as missing? Answering questions like * Why (it) is special ? * Why we need it now? * Who will use it and why it can’t be achieve otherwise? My feeling is that in order to explain the reasoning we need to emphasise the workloads types piece. We want to avoid using special and specific NFV terms, because they are frightening and not relevant for the majority of the community. So I would suggest to enrich the workload type section. Maybe add more options to explain availability schemes needs and other common cases like storing large files in burst or any other example. In addition I would add a section for “transition” time needs just because of the state of the apps. A good example for it is the “VLAN” trunking BP. It feels more like a transition need (apps today are sending traffic with VLANs) rather than a long term real need. In comparison to state or performance needs that have a better justification for the long term. My app owners friends, please don’t “jump” on the VLANs example, I assume we can argue about it…. I hope the point I am is clear though Then for each section (type) answer the questions above and link the BPs to each of those “types”. What we will achieve? * Not having special NFV terms as part of the discussion with the community * Clear reasoning for the needs * Not position NFV as not “cloudy” If make sense, we can start and working on it. Itai ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
Shall we continue this discussion? Itai On 6/9/14 8:54 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Steve Gordon sgor...@redhat.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage Just adding openstack-dev to the CC for now :). - Original Message - From: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com Subject: Re: NFV in OpenStack use cases and context Can we look at them one by one? Use case 1 - It's pure IaaS Use case 2 - Virtual network function as a service. It's actually about exposing services to end customers (enterprises) by the service provider. Use case 3 - VNPaaS - is similar to #2 but at the service level. At larger scale and not at the app level only. Use case 4 - VNF forwarding graphs. It's actually about dynamic connectivity between apps. Use case 5 - vEPC and vIMS - Those are very specific (good) examples of SP services to be deployed. Use case 6 - virtual mobile base station. Another very specific example, with different characteristics than the other two above. Use case 7 - Home virtualisation. Use case 8 - Virtual CDN As I see it those have totally different relevancy to OpenStack. Assuming we don't want to boil the ocean hereŠ 1-3 seems to me less relevant here. 4 seems to be a Neutron area. 5-8 seems to be usefully to understand the needs of the NFV apps. The use case can help to map those needs. For 4 I guess the main part is about chaining and Neutron between DCs. Soma may call it SDN in WAN... For 5-8 at the end an option is to map all those into: -performance (net BW, storage BW mainly). That can be mapped to SR-IOV, NUMA. Etc' -determinism. Shall we especially minimise noisy neighbours. Not sure how NFV is special here, but for sure it's a major concern for lot of SPs. That can be mapped to huge pages, cache QOS, etc'. -overcoming of short term hurdles (just because of apps migrations issues). Small example is the need to define the tick policy of KVM just because that's what the app needs. Again, not sure how NFV special it is, and again a major concern of mainly application owners in the NFV domain. Make sense? Hi Itai, This makes sense to me. I think what we need to expand upon, with the ETSI NFV documents as a reference, is a two to three paragraph explanation of each use case explained at a more basic level - ideally on the Wiki page. It seems that use case 5 might make a particularly good initial target to work on fleshing out as an example? We could then look at linking the use case to concrete requirements based on this, I suspect we might want to break them down into: a) The bare minimum requirements for OpenStack to support the use case at all. That is, requirements that without which the VNF simply can not function. b) The requirements that are not mandatory but would be beneficial for OpenStack to support the use case. In particularly that might be requirements that would improve VNF performance or reliability by some margin (possibly significantly) but which it can function without if absolutely required. Thoughts? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV] Re: NFV in OpenStack use cases and context
#5 is a good reference point for the type of apps we can encounter in NFV. I guess it's a good idea to start with it. Itai Sent from my iPhone On Jun 10, 2014, at 7:16 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Stephen Wong stephen.kf.w...@gmail.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Hi, Perhaps I have missed it somewhere in the email thread? Where is the use case = bp document we are supposed to do for this week? Has it been created yet? Thanks, - Stephen Hi, Itai is referring to the ETSI NFV use cases document [1] and the discussion is around how we distill those - or a subset of them - into a more consumable format for an OpenStack audience on the Wiki. At this point I think the best approach is to simply start entering one of them (perhaps #5) into the Wiki and go from there. Ideally this would form a basis for discussing the format etc. Thanks, Steve [1] http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf On Tue, Jun 10, 2014 at 2:00 AM, MENDELSOHN, ITAI (ITAI) itai.mendels...@alcatel-lucent.com wrote: Shall we continue this discussion? Itai On 6/9/14 8:54 PM, Steve Gordon sgor...@redhat.com wrote: - Original Message - From: Steve Gordon sgor...@redhat.com To: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com, OpenStack Development Mailing List (not for usage Just adding openstack-dev to the CC for now :). - Original Message - From: ITAI MENDELSOHN (ITAI) itai.mendels...@alcatel-lucent.com Subject: Re: NFV in OpenStack use cases and context Can we look at them one by one? Use case 1 - It's pure IaaS Use case 2 - Virtual network function as a service. It's actually about exposing services to end customers (enterprises) by the service provider. Use case 3 - VNPaaS - is similar to #2 but at the service level. At larger scale and not at the app level only. Use case 4 - VNF forwarding graphs. It's actually about dynamic connectivity between apps. Use case 5 - vEPC and vIMS - Those are very specific (good) examples of SP services to be deployed. Use case 6 - virtual mobile base station. Another very specific example, with different characteristics than the other two above. Use case 7 - Home virtualisation. Use case 8 - Virtual CDN As I see it those have totally different relevancy to OpenStack. Assuming we don't want to boil the ocean hereŠ 1-3 seems to me less relevant here. 4 seems to be a Neutron area. 5-8 seems to be usefully to understand the needs of the NFV apps. The use case can help to map those needs. For 4 I guess the main part is about chaining and Neutron between DCs. Soma may call it SDN in WAN... For 5-8 at the end an option is to map all those into: -performance (net BW, storage BW mainly). That can be mapped to SR-IOV, NUMA. Etc' -determinism. Shall we especially minimise noisy neighbours. Not sure how NFV is special here, but for sure it's a major concern for lot of SPs. That can be mapped to huge pages, cache QOS, etc'. -overcoming of short term hurdles (just because of apps migrations issues). Small example is the need to define the tick policy of KVM just because that's what the app needs. Again, not sure how NFV special it is, and again a major concern of mainly application owners in the NFV domain. Make sense? Hi Itai, This makes sense to me. I think what we need to expand upon, with the ETSI NFV documents as a reference, is a two to three paragraph explanation of each use case explained at a more basic level - ideally on the Wiki page. It seems that use case 5 might make a particularly good initial target to work on fleshing out as an example? We could then look at linking the use case to concrete requirements based on this, I suspect we might want to break them down into: a) The bare minimum requirements for OpenStack to support the use case at all. That is, requirements that without which the VNF simply can not function. b) The requirements that are not mandatory but would be beneficial for OpenStack to support the use case. In particularly that might be requirements that would improve VNF performance or reliability by some margin (possibly significantly) but which it can function without if absolutely required. Thoughts? Steve -- Steve Gordon, RHCE Product Manager, Red Hat Enterprise Linux OpenStack Platform Red Hat Canada (Toronto, Ontario) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit
Do we want to map ETSI NFV terms to OpenStack ones? Or maybe identify the needs themselves. Talk to the OpenStack community in the community terms and hopefully also explain why they are relevant for other cases too. Itai Sent from my iPhone On May 27, 2014, at 4:30 PM, Nicolas Thomas nicolas.tho...@canonical.com wrote: In the case a single service VM: you have 1 VNF composed of 1 VNFC. Specs tries to cover most cases, hence makes the simple ones looks too complex. The next question will be the type of services you want to put in this VM. If it ends up providing services to manage your VNF(C) then you will end up in the VNF infrastructure realm .. with guess what: other names :) On 26/05/2014 06n7, Isaku Yamahata wrote: On Fri, May 23, 2014 at 04:13:57PM +0900, Ogaki, Kenichi k.og...@gmail.com wrote: Hi All, Hi. I’m newbie to Openstack, so I want to clarify how OpenStack can implement ETSI NFV Architecture. The concept of Advanced service ln ks like Network Service in ETSI NFV Architecture as shown in Figure 3 b elow: http://docbox.etsi.org/ISG/NFV/Open/Published/gs_NFV002v010101p.pdf As the functional role, VNF (Virtualized Network Function) may be corespondent to Logical Service Instance. However, in ETSI NFV Architecture, VNF is composed of VNFC (VNF Component) or VDU (Virtual Deployment Unit) and each VNFC orVDU instance is deployed as a VM. These VNFC or VDU instances are connected by logical or physical network links in a manner of a kind of service chaining, then a VNF instance is created. In the same manner, Network Service is created from one or multiple VNF(s). Hmm, we don't use same terminology. Is there any public documentation for those terminology? The public docuemnts I can find is too high-level to understand the requirement. The first target of servicevm project is to address the case of single service in single VM(VNFC in NFV terminology?) at first. Then evolve the implementation for more complex case with experiment. My question is: Is it possible that the current OpenStack components realize an advanced service in the above manner? Meaning, an advanced service is composed of hierarchical multiple VMs. I suspect no one knows. This is why we unite to make efforts for NFV. thanks, Isaku Yamahata All the best, Kenichi From: Dmitry [mailto:mey...@gmail.com] Sent: Thursday, May 22, 2014 5:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][NFV] NFV BoF at design summit Hi Isaku, Thank you for the updated link. I'n not sure where from I get the previous one, probably from the direct Google search. If we're talking about NFV Mano, it's very important to keep NFVO and VNFM as a separate services, where VNFM might be (and probably will be) supplied jointly with a vendor's specific VNF. In addition, it's possible that VNFC components will not be able to be placed on the same machine - anti-affinity rules. Talking in NFV terminology, we need to have a new OpenStack Services which (from what I've understood from the document you sent) is called Adv Service and is responsible to be: 1) NFVO - which is using Nova to provision new Service VMs and Neutron to establish connectivity and service chaining 2) Service Catalog - to accommodate multiple VNF services. Question: the same problem exists with Trove which need a catalog for multiple concrete DB implementations. Do you know which solution they will take for Juno? 2) Infrastructure for VNFM plugins - which will be called by NFVO to decide where Service VM should be placed and which LSI should be provisioned on these Service VMs. This flow is more or less what was stated by NFV committee. Please let me know what you think about this and how far is that from what you planed for Service VM. In addition, I would happy to know if Service VM will be incubated for Juno release. Thank you very much, Dmitry On Thu, May 22, 2014 at 9:28 AM, Isaku Yamahata isaku.yamah...@gmail.com wrote: On Wed, May 21, 2014 at 10:54:03AM +0300, Dmitry mey...@gmail.com wrote: HI, Hi. I would happy to get explanation of what is the difference between Adv Service Management https://docs.google.com/file/d/0Bz-bErEEHJxLTGY4NUVvTzRDaEk/editfrom the Service VM The above document is stale. the right one is https://docs.google.com/document/d/1pwFVV8UavvQkBz92bT-BweBAiIZoMJP0NPAO4-60XFY/edit?pli=1 https://docs.google.com/document/d/1ZWDDTjwhIUedyipkDztM0_nBYgfCEP9Q77hhn1ZduCA/edit?pli=1# https://wiki.openstack.org/wiki/ServiceVM Anyway how did you find the link? I'd like to remove stale links. and NFVO orchestration http://www.ietf.org/proceedings/88/slides/slides-88-opsawg-6.pdffrom NFV Mano. The most interesting part if service provider management as part of the service catalog.
