14:02:30 #startmeeting nfv 14:02:31 Meeting started Wed Jun 4 14:02:30 2014 UTC and is due to finish in 60 minutes. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:31 o/ 14:02:31 o/ 14:02:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:33 Hello! 14:02:34 o/ 14:02:35 The meeting name has been set to 'nfv' 14:02:38 hi! 14:02:39 o/ 14:02:40 hi 14:02:42 who has joined us for our first chat? 14:02:44 * sgordon is here 14:02:45 hello 14:02:45 Hi all 14:02:47 hi 14:02:50 o/ 14:02:50 hi 14:02:50 #link https://wiki.openstack.org/wiki/Meetings/NFV 14:02:50 hi 14:02:50 hi 14:02:51 Hello 14:02:53 o/ 14:02:54 hi 14:02:57 Hi 14:02:59 hello 14:03:12 Hi 14:03:19 hi 14:03:26 hi 14:03:30 Agenda for today is on the wiki page 14:03:37 greetings 14:03:45 for future weeks, we'll switch to an etherpad to make it easier for everyone to add topics ahead of time that they would like to cover 14:03:51 * nijaba is happy to see a full house 14:03:57 yeah, a good crowd for sure 14:04:04 so let's jump to the first item ... 14:04:15 #topic mission statement 14:04:28 the first thing we should discuss is ... what do we want to achieve with this group? 14:04:41 someone has drafted a mission statement here 14:04:44 #link https://etherpad.openstack.org/p/nvf-subteam-mission-statement 14:04:50 excuse the typo in the URL :-) 14:04:55 that was me with input from 3 or four others 14:05:00 nijaba: great 14:05:12 so, everyone take a look at that and see what you think 14:05:20 i think it captures the central parts of what we talked about @ summit 14:05:21 and that must be my typo too :) 14:05:22 if we can nail something down, we'll move it to the wiki page to be more static 14:05:26 looks good to me 14:05:30 but i know there are some questions about interaction with other projects/subteams 14:05:37 particularly in the servicevm meeting yesterday 14:05:41 sgordon: yeah, let's cover that next 14:05:49 any concerns with the proposed mission? 14:06:10 +1 on mission 14:06:21 +1 14:06:21 +1 14:06:25 +1 14:06:26 +1 14:06:28 +1 14:06:28 +1 14:06:31 Any desire to pass feedback upstream to ETSI? 14:06:32 +1 14:06:33 +1 14:06:36 #agreed mission statement as drafted on the etherpad looks good 14:06:36 +1 14:06:37 +1 14:06:40 +1 14:06:42 great thanks :) 14:06:43 +1 14:06:45 +1 14:06:54 +1 14:06:56 +1 14:06:57 cloudon: hm, a good question 14:06:59 +1 14:07:00 cloudon: not a bad idea 14:07:07 +1 14:07:10 The comment about "without any special hardware or proprietary software" may conflict with the need for 3rd party CI? 14:07:23 cloudon: i don't know if we need to formally capture in mission or have it be a side-effect 14:07:31 adrian-hoban: "If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against." should cover that 14:07:40 cdub: as a side effect seems reasonable 14:07:45 adrian-hoban, mmm i think the point raised was that everything must be testable on at least 1 open source impl 14:07:47 seems like a natural outcome as we go forward 14:07:52 Happy with a side effect 14:07:52 i think we possibly need to be more specific there 14:07:58 I think the point of that was that in all cases whatever we're up to should be testable by anyone in its base form of functionality, even if there are vendor specific bonuses. 14:08:02 russellb: agreed 14:08:06 ijw, right 14:08:10 adrian-hoban: I don't see a problem with the statement 14:08:14 Ok, +1 14:08:17 cloudon: I would advice on following close to ETSI NFV terminology 14:08:20 +1 from me too 14:08:27 ijw: yeah i think that's key, that's pretty much how all of openstack is developed 14:08:31 adrian-hoban: it leaves possibility to run 3rd-party CIs 14:08:45 adrian-hoban: for specific hardware resources 14:08:51 I find the ETSI terminology too cpmplex and less relevant for os 14:08:55 bauzas: Agreed, it will be needed for some use cases 14:08:57 so let's discuss the relationship of this group with other openstack teams 14:09:00 cgoncalves: we discussed this at summit, i suggest we translate to openstack language 14:09:12 cdub, right 14:09:21 on the ETSI terminology concerns, let's come back to that in a few minutes when we get to use cases 14:09:33 so, other groups, in particular, servicevm 14:09:38 russellb: ok 14:09:54 in general, i think it makes sense that some development efforts will be big enough that some specific coordination is fine 14:10:03 and i think this group is a bit more broad focused 14:10:11 russellb: what is the question, exactly? 14:10:13 across all of openstack, and gathering requirements 14:10:23 cdub: there seemed to be some concern with overlap with the servicevm effort 14:10:26 What's the issue with servicevm? 14:10:26 sgordon: have some comments on that? 14:10:37 i was just lurking the minutes there 14:10:45 there is some overlap in terms of concerns about ETSI terminology 14:10:47 and use cases 14:10:57 OK 14:10:58 russellb: ah, ok. it is likely that servicevm is relevant 14:11:00 servicevm has mostly overlapped requirement as https://wiki.openstack.org/wiki/ServiceVM/neutron-and-other-project-items 14:11:11 so hopefully we can keep the ETSI terminology / use case translation work focused here 14:11:12 although servicevm is a more specific effort in terms of having a specific set of deliverables 14:11:12 russellb: what is the overlap? is there any development charter for the NFV subteam yet? or are we still working on requirements? 14:11:16 now in the form of a service 14:11:21 ServiceVM has a large non-overlapping requirement, too, though 14:11:37 whereas i see this effort as more broadly formulating and driving NFV requirements into openstack 14:11:39 I know there is going to have an open source project named OPN. This NFV team get requirement from vendors or operators directly or just from OPN? 14:11:43 wherever that may be 14:11:52 NFV is creating user-run services. ServiceVM is about providing APIs to those services through Openstack. And in both cases I don't think we actually care who does the work as long as it gets done 14:11:54 so servicevm, neutron, nova, heat, ipv6 subteam etc 14:11:54 note that besides servicevm there is also the advanced services sub-team whih is covering some relevant NFV work items 14:12:10 ijw, +1 14:12:21 NZHOU: as in any community, I think we get our requirements from the community 14:12:22 ok, seems we're generally all with the same understanding about how these groups relate 14:12:35 wanted to make sure there wasn't major concern there 14:12:39 NZHOU: Both OPN and from vendors/operators 14:12:47 i dont think there is a major concern 14:13:00 but we should collaborate when it comes to terminology and use cases 14:13:00 ijw: ok 14:13:03 if it makes sense 14:13:10 #topic use cases 14:13:19 rather than independently creating two etsi -> openstack glossaries for example 14:13:22 we've done a nice job early on with gathering a big list of blueprints 14:13:26 cgoncalves: The advanced services stuff is all about plugging the service VM services - and others - into Openstack. Again, they'll use the tools we make, but we won't have a complete overlap 14:13:34 i think one big work area for us is the use cases and terminology translation for openstack 14:14:10 I don't know how many ETSI bods we have, I know adrian-hoban is one... 14:14:12 right, and the question there is do we want to target specific VNFs or more generally translate the ETSI NFV use cases 14:14:16 what would we like to accomplish in this area? 14:14:31 in a way it's, how do we define success 14:14:32 II am not that sure if that mapping is actually required 14:14:46 smazziotta: I think you are in ETSI NFV, right? 14:14:48 I thought we want to drive requirements. The ETSI use cases are far too high level 14:14:52 I guess most ETSI folks are familiar with OpenStack terminology as well 14:14:55 Yes 14:14:57 from an openstack developer perspective, I feel like we need a "tl;dr" of why this stuff is important 14:15:01 Personally, I was more interested in making it possible to run VNFs. I don't think we should be 'creating VNFs' for ourselves (and there perhaps the serviceVM guys really do want to do that) 14:15:04 not rwally 14:15:07 imendel, agree 14:15:12 I am in ETSI NFV too. 14:15:16 yes. I need to register enovance :-) 14:15:17 fjrs, agree 14:15:18 imendel, i am just trying to get a feel for how we get to something more specific 14:15:30 i gree, we need somthing specifc 14:15:45 russellb: should we aim to have that for next week? 14:15:56 it would be nice to have something, even brief, written up that ties blueprints to the "why" 14:15:56 OpenStack fits _mostly_ in what ETSI-NFV describe as a Virtualisation Infrastructure Manager (VIM) 14:15:57 ijw: would be happy to work with you on writing about this 14:15:58 cdub: yeah 14:16:06 Terminology in openstack is clear for most of ETSI folks 14:16:13 adrian-hoban, agree 14:16:16 maybe a few people can go off and start a first cut at something? 14:16:22 adrian-hoban:+1 14:16:28 russellb: ok, i'll help with that 14:16:33 russellb: volunteering 14:16:44 russellb: Are you looking for a terminology translation or use cases? 14:16:50 ok great, who wants to coordinate it? 14:17:01 mainly use cases that the blueprints can be tied to, personally 14:17:02 Certainly we should draw the mapping diagram, if nothing else; it's always the first thing people want to see 14:17:11 so far ijw, cdub, nijaba 14:17:12 ijw: agreed re: building vnfs 14:17:15 i am happy to assist as well 14:17:17 adrian-hoban: I think russellb was talking about why the listed blueprints are relevant to NFV according to use cases 14:17:23 cdub: OK, want to coordinate it? 14:17:32 russellb: sure 14:17:39 s3wong: Ok, makes sense 14:17:40 In addition to VIM, there is some intersection between Heat and possibly new projects like Climate and the Management/Orchestration (MANO) 14:17:40 me too 14:17:44 russellb: so sgordon, nijaba ...anyone else? 14:17:47 #agreed cdub to coordinate a first pass on starting some openstack use case documentation, contact him if you'd like to help 14:17:53 #undo 14:17:55 Removing item from minutes: 14:17:55 There are ~9 key use cases that are being assessed 14:18:00 #note cdub to coordinate a first pass on starting some openstack use case documentation, contact him if you'd like to help 14:18:06 I will help too 14:18:11 i'd also like to help 14:18:20 OK, let's come back to this next week and review what you guys come up with :) 14:18:21 cdub: how can we contact you? 14:18:31 chrisw@sous-sol.org 14:18:32 and we'll have something more specific to poke holes in and discuss 14:18:48 Use cases in NFV are too detailed and telco-oriented to establish a mapping 14:18:56 may be slow until later today to reply 14:19:10 GGarcia: we need to dig under 14:19:12 telco oriented is rather the point of NFV, no? 14:19:13 GGarcia, we need to find a middle ground to progress 14:19:41 Also, kind of the worst cases of what you'd like from network services, so in some senses the best way to drive an architecture. 14:19:59 So the question I guess is what we do understand as use case 14:20:03 perhaps a small contribution to the ETSI-NFV VIM part: https://review.openstack.org/#/c/92477/6/specs/juno/traffic-steering.rst,unified (problem description section) 14:20:31 FJRamon: that's a good question, and we started at fairly high level (ETSI driven) 14:20:32 FJRamon, cdub, sgordon: if we are meaning by use cases the ones here (http://www.etsi.org/deliver/etsi_gs/NFV/001_099/001/01.01.01_60/gs_NFV001v010101p.pdf), it is too complex 14:20:48 GGarcia, we are actually saying that is too high level i believe 14:20:54 GGarcia> nfv use cases maps very well with HPC use cases.. that'd enrich the target cases for OSP... not to say that numa, sriov, etc generally speaking high performance VMs are a need today 14:21:20 Yes, that is correct 14:21:23 GGarcia: too high level actually 14:21:42 We have time. Let's see what we can do with the NFV docs in a week. We're not saying other people can't work independently if they have bright ideas and there's a mailing list out there too. 14:22:06 sounds good 14:22:08 cgoncalves, suggest adding it to the wiki if it's relevant for tracking 14:22:14 we can come back to this at the end in "open discussion" if needed 14:22:17 #topic blueprints and tracking 14:22:23 Agreed that they are high level, but we can start with them and decompose into lower level requirements that are being expressed in the current set of blueprints that we have captured. 14:22:26 so, we've got a big list of blueprints, a good start :) 14:22:35 adrian-hoban, that's the idea yeah 14:22:37 1) how complete is the list of active work? 14:22:43 tvvcox: agreed and it's something i know i've been using to advocate 14:22:45 :) 14:22:50 and 2) any thoughts on a better approach to tracking it all than wiki hacking? 14:23:08 so i think it was ijw raised on the list 14:23:21 we need to define what is actually realistic for juno 14:23:21 russellb: like I said on the ML, I think what we have there is a lot of work but a lot of it is nice-to-have stuff 14:23:23 russellb: we could make use of a gerrit dashboard 14:23:30 and the low hanging fruit that would get best bang for buck 14:23:34 You can do NFV if only you can get traffic from one VM to another, which is currently at issue 14:23:42 russellb: provided all specs are tracked 14:23:44 bauzas: cool idea, willing to take a look at that? 14:23:53 Re 1), I think this is just the starting point, but a good one that we can build on 14:23:59 right that sounds like a good idea bauzas 14:24:00 Beyond that, we should work out how to rate the rest and focus on what we can agree on and accomplish when we have the ground work 14:24:04 russellb: okay, count me in 14:24:06 im concerned that the wiki will grow stale 14:24:09 #action bauzas to take a look at building a custom gerrit dashboard 14:24:16 so ideally that might provide something we can more easily automate 14:24:37 cdub> there's many offerings from public cloud providers such as Amazon, Google, Verizon where high performance VMs are the differentiator 14:24:40 yeah, i was concerned about the work to keep it current, because if not current, it's not that useful 14:24:46 ijw: an issue for getting traffic from one VM to another? 14:25:00 Yes, at line rate it is 14:25:12 ijw: yeah, i think some prioritization is a good idea. 14:25:14 FJRamon: +1 14:25:20 tvvcox: exactly 14:25:29 both priority, as well as some breakdown of what we think is achievable in each release 14:25:30 tvvcox: e.g. look aw hpc aws flavors ;) 14:25:34 based on who we know is working on stuff 14:25:35 ijw: I think it's more complex than just connectivity, line rate, jitter, latency characteristics all important 14:25:37 FJRamon, cloudon: +1 40Gbps from one VM to another without loses 14:25:41 s/look aw/look at/ 14:26:07 i think the dashboard will be helpful 14:26:12 but does that also help with priority? 14:26:16 i don't think so ... 14:26:20 the other thing i started doing was tagging bugs 14:26:20 sgordon: nope 14:26:21 with nfv 14:26:24 adrian-hoban: fair point, but again, you can test stuff with less than that 14:26:28 unfortunately you cant do that with BPs 14:26:29 i think we need something else to communicate priority and release breakdown 14:26:38 sgordon: that's only a high-level view of specs and patches 14:26:45 bauzas, right 14:26:55 we don't really have anything for that in openstack infrastructure today 14:27:00 so we may just be stuck with doing that on the wiki 14:27:02 russellb: +1 14:27:06 GGarcia,FJRamon: though lots of valuable control plane NFV apps don't need anywhere near line rate of course 14:27:14 yes 14:27:15 s3wong: passing traffic without having it dropped by the fabric and firewalled by security groups, for starters 14:27:16 Yes 14:27:26 i went to the storyboard session at summit but it doesnt quite seem ready for this 14:27:29 But there is not much work needed there 14:27:31 (in particular no dep tracking) 14:27:35 something to keep an eye on 14:27:46 The thing is that data plane is the elephant in the room 14:27:53 +1 14:27:57 Most of the network equipment requires that 14:27:57 cloudon: true, i usually describe as spectrum 14:28:01 russellb: if we create different gerrit users for P1, P2, etc. then we got our views :) 14:28:01 #agreed build gerrit dashboard for current design/code status, continue to use wiki to document priorities and release targeting for now 14:28:05 ^^ that sound good? 14:28:14 Well, given we meet for an hour a week, I think if we picked the first five to discuss over the next week we could make that work - more than that and how do we talk about them? 14:28:19 i think we should isolate the use cases between performance and functionality 14:28:20 FJRamon, GGarcia so i think that feeds into the use cases discussion that cdub will follow up with the others 14:28:32 I agree 14:28:36 agree 14:28:38 russellb: if we say that this patch is P1, then we add P1 user as reviewer of that patch 14:28:39 e.g. "which blueprints directly relate to improving the control plane performance" 14:28:39 ijw: i like that 14:28:46 Yes, we need to make sure we can deploy the data plane at sufficient performance. A number of items listed in the NFV wiki will help 14:28:59 ramk_: absolutely 14:29:07 ramk_, performance, determinism, reliability 14:29:11 sgordon: that's the goal of tagging blueprints :) 14:29:14 adrian-hoban: maybe you could point at the relevant stuff in an ML email? 14:29:21 #topic open discussion 14:29:30 ijw: Sure thing 14:29:33 ramk_, sgordon: +1 14:29:43 it has been kind of open discussion throughout, but that's ok :) 14:30:02 Can someone tell me if I got the BPs I wrote right, or if I missed anything? 14:30:05 russellb: current ML [NFV] tag is ad-hoc, at some point perhaps we formalize w/ infra request? 14:30:17 russellb: and ditto for #openstack-nfv 14:30:20 cdub, probably should do that now 14:30:23 cdub: yes, that's easy enough 14:30:25 cdub: +1 14:30:32 #action russellb to formally request NFV mailing list tag 14:30:36 sgordon: i just figured we should prove we need it (by using it ;) 14:30:45 #action russellb to request infra management of #openstack-nfv IRC channel 14:30:51 Howdy! I am working on an NFV deployment for Deutsche Telekom this year. We want to use the standard upstream Juno release. We would need to upstream around 100 lines of simple non-disruptive code into OpenStack during this cycle. That's a VIF and ML2 mech driver for the open source Snabb NFV (http://snabb.co/nfv.html). If we get this upstream then it saves us maintaining a fork and it also makes it available to the community. 14:30:54 ijw: please refresh the wiki page. just added the traffic steering BP. hope it is relevant to this team to track 14:31:17 cgoncalves: certainly wants consideration with the rest 14:31:32 Our blueprints, specs, and code are submitted last week and proposed for juno-2. There is a dependency on a new QEMU feature that should upstream any week now. 14:31:43 lukego, thanks - that one is already listed in the wiki right? 14:31:46 Yep 14:31:50 :) 14:31:52 :-) 14:32:04 I'd be surprised if you needed much help with that, lukego 14:32:23 lukego: have you had feedback on qemu dep? (e.g. capability negotiation?) 14:32:28 russellb: how do we work on priorization? Vote? 14:32:30 * ijw sits next to a Neutron core and can beat him with a stick till he gives you a +2 if you like 14:32:49 ijw: nice to have :) 14:32:55 cdub: afaik we are targetted for QEMU 2.1 and should merge real soon now. 14:32:56 lukego, where is the qemu dep tracked 14:32:56 * cdub notes ijw's offer down for later 14:33:04 ijw: it will be better if two :) 14:33:06 i've set up an etherpad to work on the agenda going forward 14:33:07 lukego, link to that as well might be useful 14:33:08 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:33:15 two cores, or two sticks? 14:33:22 both 14:33:30 nijaba: fight over it? i'm not sure yet :) 14:33:31 lukego: We will need to check for overlap with some other proposals in the wiki 14:33:32 ijw: The risk I see is core devs being overloaded with too many BPs and these ones falling through the cracks. 14:33:41 What practical help do folk envision this group being able to provide to help e.g. lukego's work reviewed and accepted? Direct reviewing, peer pressure etc? 14:33:49 nijaba: i think we should discuss requirements in detail, a few each week as time permits, and have priority be a part of that discussion 14:33:52 lukego: do you have libvirt changes you need, too? 14:33:54 lukego, yes that is where as a group we need to help prioritize 14:34:15 ijw: it is submitted to upstream libvirt and pending review 14:34:17 I’d like help to have the code reviewed so that it’s good enough to be merged upstream 14:34:17 russellb: sounds good. 14:34:23 cloudon: best help is always work, so go review 14:34:34 (and I am willing to help review the other stuff we prioritize here) 14:34:39 russellb: priority should also be linked to commitment to do something too 14:34:46 cloudon: all of us can help code-review; and with enough +1s we will eventually get core's attentions 14:34:51 nijaba: +1 14:35:01 s3wong: have you looked at setting up CI? 14:35:07 I think that's requirement if you have a new neutron driver 14:35:28 err, i mean lukego 14:35:38 Our code is submitted to QEMU, Libvirt, Nova, and Neutron. Linked on the wiki (if you search for “Snabb”). We are blocked on QEMU merging our code right now but once that happens I hope we can merge everything quickly. 14:35:39 It is, and mestery's in the corner over there if you need expert advice on anything else Neutron 14:35:58 I'm already in contact with lukego on his stuff. :) 14:35:58 * ijw hands you a stick 14:36:06 russellb: I will setup 3rd party CI. Have to coordinate that with mestery. I am already developer/maintainer of one mech driver for Neutron so I know the ropes of that part pretty OK 14:36:11 less sticks, more carrots 14:36:17 lukego: ah cool 14:36:21 It'd need to be a really tough carrot. 14:36:29 I always use carrots, never sticks. :) 14:36:47 Thanks all of the encouraging comments/suggestions (!) 14:37:34 lukego: Can you also have a look at some of the other blueprints related to hugepages & user space vhost? 14:37:47 adrian-hoban: I looked briefly but saw no code ? 14:37:58 lukego: On the way... 14:38:09 OK. I will follow those BPs. 14:38:12 lots of this stuff is just proposed designs so far 14:38:12 :q1 14:38:19 but it's important to get feedback on the designs 14:38:26 because that covers how we expose these things in openstack 14:38:30 which is often quite tricky 14:38:45 to do it in a way that is cloudy enough 14:39:02 so we need to make sure it's acceptably cloudy, but also satisfies what people actually need 14:39:17 I have everything implemented to an “alpha” level now. heavy development/testing is happening on code outside the tree during the Juno cycle. 14:39:27 i am afraid of those being too hw specific 14:39:56 russellb: Agreed, we need to give the NFV guys enough of control and at the same time keep the rest of the community safe 14:40:10 Imendel: determinism and high performance requires some HW specific 14:40:10 as per russelb remark 14:40:11 On BP review, please express horror and disgust on the ones I stuck up in a hurry - they really are blockers for a lot of things and I want to get them cleared out if people are happy with the proposals. 14:40:38 (horror and disgust mainly at the formatting, they don't even pass spec tests right now...) 14:41:18 ggarcia , not sure i agree. at the end apps shoudnt care about hw choices 14:41:21 ijw: fyi you can just run 'tox' locally with no args to verify the specs 14:41:33 I suspected there'd be a command, cheers danpb 14:41:57 ijw: I gave some comments on BP. but it was quick comments. later I need to look at it closely. 14:42:02 ijw: yeah, and let me know if you have trouble with it 14:42:11 Imendel: There is a need in NFV to be more specific about certain aspects of HW. Scale out cannot solve all of the perf related items we need to consider 14:42:29 Agreed 14:42:31 ijw: thanks for filing them. even for serviceVM team some of those items were raised during the J-Summit 14:42:42 adrian-hoban, FJRamon: agree 14:42:51 ijw: which spec are you referring to, sorry? 14:43:02 russellb: doubtful - it was 2am and I was more interested in making sure they went up than whether they passed test, I wasn't exactly expecting them to go through first time of trying 14:43:03 s3wong: agree 14:43:13 not saying tools shluldnt exist. but being very specific is a sleepery road 14:43:13 cgoncalves: the three in the first table on the meeting page 14:43:35 ijw: ah, thanks. 14:43:43 on perf and determinisme , we can document precise use-case so that we can justify the need to these features in Openstack 14:43:46 s3wong: the problems we both hit aare much the same in terms of plumbing 14:44:02 Imendel: some NFV use case will require some perf guarantee and HW knowledge could help here 14:44:13 Yes, that it the point 14:44:25 agree 14:44:39 NFV use case like CDN or any data-plane VNF 14:44:40 smazziotta: It's not something you can work with without infrastructure help, certainly, be it constraint specifications or monitoring, but I don't have a mental picture of what you need to ask for there, I have to say, that's where adrian-hoban could really help 14:44:51 i am aware of the use cases. i really dont think that nfv is the only one facing perf issues. 14:45:08 ijw: agreed. 97716 was raised during transparent firewall discussion, and 97715 was repeatedly brought up just for having a service VM pool 14:45:14 it doesnt means that nfv = hw aware. 14:45:25 smazziotta: I think that is part of the action a few of us agreed to work on for review next week 14:45:31 Yes, that is true 14:45:33 imendel: agree 14:45:38 ChristianM_: you have to be careful about 'HW knowledge' - there's an abstraction between you and the hardware. You really need to do things independent of HW at the API level. 14:45:51 ijw: yes, and that's where things get tricky 14:45:54 (I say this having had 101 discussions about that sort of violation as a quick fix) 14:46:00 express something that allows you to express your performance requirements, without being hw specific 14:46:03 Imendel: But it is also true that I/O intensive only is essential in NFV, so you need to take different things into account 14:46:24 russellb: yup, and monitor to make sure you can take corrective actions 14:46:25 russellb, yes 14:46:26