14:03:41 #startmeeting nfv 14:03:42 Meeting started Wed Jun 18 14:03:41 2014 UTC and is due to finish in 60 minutes. The chair is russellb. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:45 The meeting name has been set to 'nfv' 14:03:48 \o 14:03:50 hello 14:03:51 hello! who's around to talk NFV? 14:03:52 o/ 14:03:54 hi 14:03:55 Hi 14:03:55 here 14:03:56 hi 14:03:57 hi 14:03:58 o/ 14:03:59 Hi there ! 14:04:10 hi 14:04:18 yo! 14:04:19 o/ 14:04:25 #link https://wiki.openstack.org/w/index.php?title=Meetings/NFV 14:04:28 agenda on the etherpad: 14:04:49 #link https://etherpad.openstack.org/p/nfv-meeting-agenda 14:04:59 #topic review action items 14:05:09 so, infra 14:05:13 cdub not here so we'll skip his 14:05:15 no cdub 14:05:15 bauzas: o/ 14:05:24 russellb: sure 14:05:35 russellb: so, I made a proposal 14:05:40 * russellb bauzas to make gerrit dashboard 14:05:42 for context 14:05:54 bauzas: have a link? 14:05:58 russellb: the idea is to make use of Gerrit for having a dashboard of all blueprints and patches 14:06:09 https://review.openstack.org/100559 14:06:23 #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/037941.html 14:06:25 im a little concerned about the invasiveness of having to add a tag to every commit 14:06:29 #link https://review.openstack.org/100559 14:06:37 yeah, i think we should avoid going that route 14:06:40 mainly an issue for the existing ones of course which will get sent for a loop 14:06:40 that's based on a new tool gerrit-dash-creator 14:06:55 sgordon: I do understand the problem 14:07:14 sgordon: we only need to find a way to discriminate all the NFV patches from the other ones 14:07:17 or patches from people not necessarily in this group 14:07:36 what if we maintain a list of gerrit topics in dash creator? 14:07:38 russellb, right 14:07:52 that's possible, but that will increase the query 14:07:55 yes 14:08:01 will be pretty big ... 14:08:10 and will require to shorten the url each time we add a new change 14:08:12 but at least, in theory, you do an update once per blueprint we're tracking 14:08:16 oh right 14:08:26 the short url isn't static ... 14:08:30 hi all 14:08:35 russellb: right 14:08:36 can link to it from our wiki page, and update that link 14:08:39 i suppose. 14:08:46 that's possible 14:09:00 but that requires to vote on each change 14:09:01 patch subjects should be short by definition and adding some prefix make even less space for text 14:09:22 for each new blueprint, we have to issue a new side patch for gerrit-dash-creator 14:09:28 radek, the tag doesnt go in the subject 14:09:30 in order to update nfv.dash 14:09:47 mmm 14:09:51 ahhh ok so it change a lot and makes sense for me too 14:10:12 really wish you could tag reviews in gerrit, without updating patches 14:10:21 of course, non-existant gerrit features aren't helpful here :) 14:10:27 radek, if we take the tag approach it is just somewhere in the commit msg - but it still means adding it to every single one 14:10:40 russellb: labels are here for that, but that means it would create a new column 14:10:52 i think that is ok, no? 14:10:54 new column in gerrit? 14:11:01 Problem we're going to have is where a perfectly respectable proposal is *also* an NFV one, so people who submit and approve wouldn't necessarily know to tag them 14:11:11 ijw, exactly 14:11:13 ijw: yep 14:11:20 ijw, and also may be annoyed if someone tags it for them 14:11:28 i would be 14:11:32 (annoyed) 14:11:37 ijw, that's why i dont like that approach, even if the alternatives mean more work on our part 14:11:40 I was certainly surprised mine had been tagged... 14:11:50 Gerrit now allows that 14:11:50 But it's our problem, so such is life. 14:12:05 bauzas, allows? 14:12:09 bauzas: can you clarify what gerrit allows? 14:12:31 ijw: I mean, now anyone can change a commit msg 14:12:41 that was allowed before 14:12:45 you just push an update to the review 14:12:48 yeah 14:12:49 Yes - true, but if we don't get to a BP till it's accepted then what? 14:12:53 right, but not in the interface :) 14:13:17 bauzas: ah.. 14:13:25 Better if you extracted the specs, bps or whatever from a wiki page and used that list 14:13:29 ijw, we celebrate that it was accepted and morn the fact that we cant track it automatically 14:13:55 ijw, right - i guess the missing bit is how to do that *and* build the status updates in automatically somewhere 14:14:05 ijw: the alternative is to update https://review.openstack.org/100559 with all the topic names for the blueprints 14:14:12 i mean we have the list on the wiki today, incl. statuses, but updating them is going to be v. manual 14:14:20 bauzas: that's what i prefer right now i'm afraid 14:14:38 a gerrit dashboard would be super helpful to me as a reviewer, too 14:14:47 so i can go target NFV related spec and code reviews 14:14:53 bauzas: trying to avoid wasting people's times with relatively pointless reviews - I think we all have better things to do with our lives than that... 14:15:13 ijw: which pointless reviews? 14:15:22 russellb, when the patch gets bumped for the tag add 14:15:27 yes 14:15:31 +1 we sure do have better things to be spending time on, 14:15:32 russellb, bauzas was saying this doesnt count as a trivial 14:15:50 yeah, i think that's agreement that the tag approach is a no go 14:15:54 yes 14:16:04 how about trying a list of gerrit topics in the dash creator for now 14:16:10 russellb: I'm presuming bauzas is proposing we commit the review list to his code, which means a review just to add each entry 14:16:23 ijw: right, that's the alternative 14:16:25 ijw, correct 14:16:28 each gerrit topic, which should cover several patches 14:16:35 an update to the dash per blueprint, vs per patch 14:16:39 ok, I can do that 14:16:48 well, that's the alternative to get a dash in gerrit which will show up to date status for the given list 14:16:52 bauzas: willing to do a first cut on that? 14:16:55 means topic/bp addition remains manual 14:17:09 that only requires to send a git-review for each update, but that's life 14:17:15 bauzas: *nods* 14:17:27 i'd just script the first cut at it 14:17:37 russellb: yey, we can try 14:17:42 sgordon: write a script which just queries the status from gerrit and generates a static HTML page once an hour with status 14:17:45 parse the wiki page table for blueprint URLs, and use topics of "bp/" 14:17:53 danpb: or that. 14:18:10 scrape wiki for blueprints, scrape blueprints for reviews, scrape reviews for status, generate page :) 14:18:13 could be done entirely outside gerrit with no real difficultly as long as there's a list of BPs /somewhere/ to drive it from 14:18:34 danpb, that is pretty tempting to me tbh 14:18:42 https://xkcd.com/208/ 14:18:53 danpb, no problem that cant be solved by adding more bash right? 14:18:54 sgordon: yeah 14:18:59 bauzas: what do you think of that idea? 14:19:03 sgordon: perl please ;-P 14:19:16 Go for it, people. 14:19:17 russellb: that's sexy 14:19:22 ok 14:19:25 bauzas: willing to write it? :) 14:19:29 danpb: you luddite. ;) 14:19:39 russellb: yup 14:19:42 bauzas: awesome! 14:19:56 * ijw <- JAPH 14:20:12 #action bauzas to do a first revision of a script to build an automatic status page from list of blueprints on the wiki (and post it in git somewhere so others can help) 14:20:13 only downside is you may want to query the launchpad api at some point but we will deal with that monstrosity when you get to it... 14:20:20 yeah... 14:20:25 scrape blueprint whiteboard for list of reviews 14:20:27 (launchpadlib's support for blueprints is....interesting) 14:20:27 that'll be fun. 14:20:32 and by fun i mean *headdesk* 14:20:40 ok 14:20:44 next topic :) 14:20:53 so i think the next AIs were around use cases 14:20:59 * russellb nijaba to write up a description of what nfv is on the wiki page 14:21:03 nijaba, i believe added a desc 14:21:04 wiki page has been updated! 14:21:06 done: https://wiki.openstack.org/wiki/Teams/NFV#What_is_NFV.3F 14:21:14 Yeah - I missed last weeks' meeting but I think we have an issue with the use cases 14:21:15 sounds good to me, much appreciated 14:21:24 #link https://wiki.openstack.org/wiki/Meetings/NFV#What_is_NFV.3F 14:21:24 it's a first version, feel free to update! 14:21:41 ijw, whats your concern? 14:21:42 +1 14:21:44 They're a level removed from what we can make use of, very abstract. Unles syou actually choose some implementation details - as in, use cases *with Openstack involved* we can't do much with them 14:21:52 +1 14:21:58 I added ETSI-NFV use case descriptions and a first cut of mappings to blueprints 14:22:05 ijw, right - primarily the ETSI ones right 14:22:35 we need to drill into them at the same time 14:22:45 A contribution from Calum Loudon has mapped blueprints to a Session Border Controller 14:22:52 yes 14:22:55 i added that to the wiki 14:22:55 Case in point, the current ones all map pretty much identically to the BPs, which may be true but is not remotely helpful 14:23:14 sgordon: thanks for doing that 14:23:20 adrian, where is that contribution from Calum? 14:23:23 I think we need scenarios in which we're using Openstack in a specific way to implement an ETSI use case, which would then allow us to say 'these BPOs are relevant to that' 14:23:25 well, i think there is a reality that there is a core subset that are going to apply to most 14:23:38 alank35, https://wiki.openstack.org/wiki/Meetings/NFV#Contributed_Use_Cases 14:23:40 alank35: ML, now on wiki coiurtesy sgordon 14:23:40 #link https://wiki.openstack.org/wiki/Meetings/NFV#Contributed_Use_Cases 14:23:52 sgordon: true, but e.g. the scheduler is useful to most but essential to none. 14:23:59 cheers steve 14:24:03 ijw, agree 14:24:19 ijw, mainly wondering if i will see many/any that dont want sriov or dpdk for example 14:24:34 Also, and on a separate point, Neutron service chaining is about defining chains between Neutron aaS services and is not what NFV guys would consider to be service chaining, so I think that BP is actually listed when it shouldn't be 14:24:42 sgordon: I have some control plane examples which don't 14:24:55 cloudon, would be great to share - i really liked the way you structured the first one 14:25:12 Was the Session border controller example the sort of specifics people are looking for? 14:25:26 ETSI-NFV use cases are very high level and target applications in each could range from low to high end devices. Focusing on a particular application is probably more helpful 14:25:37 adrian-hoban, right 14:25:48 adrian-hoban, i still think it's useful for mapping the two worlds 14:25:55 +1 ijw on service chains 14:26:01 adrian-hoban, need to put more specific examples into those categories 14:26:08 ijw: how would NFV guys define service chaining? 14:26:26 i think that sbc is perahps implementation specific 14:26:45 cloudon, i think so - i think we need to come up with a better way to highlight the mapping to bps 14:27:03 cloudon, perhaps the way adrian-hoban formatted it into the table for the (admittedly broad) etsi ones for example 14:27:23 if we list them all out the way i did initially for the SBC example in the wiki then it's not going to be very easy to refer to 14:27:40 s3wong: for NFV it's more about routing a packet through multiple VMs in a sequence (for some definition of 'routing', there's several options with different technologies that are visible to differing extents to the services) 14:28:20 sgordon: +1 14:28:21 sgordon: on the use cases, I'm not saying we can't use the ETSI ones, I'm saying we need concrete examples defined from the ETSI ones. 14:28:36 ijw, completely agree 14:28:46 A middle layer of mapping, if you like 14:28:57 ijw, sgordon: I'll contribute concrete example for ETSI #5 14:29:11 Simple answer is probably if we all have a go at one. 14:29:18 #action cloudon to provide a concrete example for ETSI # 5 14:29:29 in my mind, the main focus and starting point should be on what additional config options do we need to get Openstack to support for NFV 14:29:50 from this point you can ensure on boarding and deployment and provisioning of NFV in Openstack 14:30:01 alank35: well, we have some BPs up, one of which I see Racha took on 14:30:26 i do think the priority list of 3 14:30:34 The issue I have is that we're talking about stuff that's a bit down the road and not prioritising or putting our effort into the immediate shortcomings (because while I put three up I don't think they're the only ones) 14:30:35 covers some of the real burning "we cant work without this" items 14:30:35 yeh, not sure where that will land 14:30:50 ijw, right 14:30:57 Well, j.2 is 4 weeks, we can target that and get the short term stuff up 14:31:19 ijw, so there is really two factors - how close/realistic things are for juno and how important they are 14:31:21 alank35: the scope of NFV is very broad to me and not sure if we can define like a list of options we can/need add 14:31:30 sriov for example i notice the design got approved yesterday 14:31:59 sgordon: sriov in nova project ? 14:32:00 sgordon: the priority list wants doing for Juno, as far as I'm concerned, and targetting j.3 would be daft because the cores get slaughtered with all the reviews in j.3. 14:32:04 radek, yes 14:32:10 ijw, yep 14:32:49 The platform performance (throughput and latency) impacting blueprints are likely to be needed by many NFV workloads (again depending on the class of device) 14:32:50 ijw, highly likely in nova for example there will again be a point early in j3 if not where code has to be up or they get pushed out 14:33:02 ijw would agree, i think we will waste time focusing on usecases that are perhaps not too vital in the end 14:33:20 So - on a practical point, how do we get them done? Can I suggest people promise to review them today and I'll do a round of updates tonight if they're needed. Volunteers also welcome, I'll have a word with our devs but I'm not sure I can promise we'll do all of them 14:33:21 adrian_hoban_ +1 14:33:34 SRIOV is kind of base which will be needed in other projects components to and it's close tied to performance 14:33:36 and most likely given what may end up happening is that we fullfill usecases for a limited number of vendors implementation 14:33:41 sgordon: that date is aug 21 14:33:41 ijw, i think review cycles from people who understand how they use these things are crucial 14:33:45 https://wiki.openstack.org/wiki/Juno_Release_Schedule 14:33:49 ijw, and an area where this group can help 14:34:09 radek: SRIOV is not an essential - again on the implementation cases, you can choose to use it or not. But yes, it's a significant case 14:34:15 ijw, the worst possible outcome would actually be for some of these to be implemented in a way that they cant be used for NFV 14:34:32 russellb, thanks 14:34:32 ijw; sure can help on the review 14:34:36 is SRIOV requiring some PCI refactoring in Nova? 14:34:37 #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 14:34:52 bauzas, https://review.openstack.org/#/c/86606/ 14:34:57 So: first, review the specs, now up, now updated (and I've been very slow on that). Then, volunteers for coding (Ericsson have one, which is great, the other two are ownerless at the moment). 14:34:58 ijw: I think PCIe passthrough and/or SR-IOV are essential if your performance requirements warrant it 14:35:25 adrian-hoban_: There's more than one way to skin a cat: DPDK, Contrail, Snabb... 14:35:48 Point being it's significant, granted, but not a blocker. 14:35:50 ijw: +1 14:36:00 bauzas: not sure if SRIOV is fully supported by libvirtd and nova changes will be required too 14:36:12 radek, libvirt has supported it for years afaik 14:36:14 sgordon: thanks 14:36:30 radek, problem has been exposing it up the nova/neutron stack 14:36:32 Certainly we should push forward on it and I think it's a good idea that we flag any changes in this meeting we should be reviewing but I'm not about to call it core to what we need. 14:36:34 ijw, adrian_hoban_ : Well, the alternative is the vSwitch, which consumes extra CPU and memory resources 14:36:40 sgordon: my concern is that PCI passthru in Nova requires a little refactoring 14:36:41 s/the/an/ 14:37:04 bauzas, the existing impl. or the sriov additions? 14:37:14 nah, the exisiting impl 14:37:15 sgordon: not sure about this but spoken in Atlanta with one of RH developers and there is a lot of things missing there yet 14:37:19 bauzas, tbh i can only suggest to get involved in the design/discussion 14:37:29 sgordon: will do 14:37:35 ggarcia: Or at least, OVS is an alternative. a virtual switch or router of some sort is pretty much the only other option, and yes, you use CPU to implement it, regardless of how efficient it is, but OVS is not the only example of that and there are different and more efficient sorts out there. 14:37:40 radek, i suspect you mean at the PCIe lane topology level - which is really additional 14:37:44 sgordon: anyway this is very detaild discussion out of today scope 14:37:48 radek, it has supporting for passing through VFs today 14:38:15 ok 14:38:26 so the action item here appears to be moar reviews in general 14:38:27 So: drifting back on topic. Please, review core BPs. Propose more core BPs. Volunteer to implement core BPs, they really need owners by next week (and code, in a fantasy world) 14:38:50 right so spec reviews but also code reviews will start coming for some of these 14:38:55 ijw: Many ways to architect the system. Different performance trade-offs require different methods. We need to accommodate these methods for the VNF developers 14:39:39 * russellb reviewed some NFV related specs in the last week :) 14:39:45 and helped get the SR-IOV one approved, yay 14:39:49 ijw, adrian-hoban: Definitely PCIe passthrough and SR-IOV are needed to get the most of a server. With OVS, you waste resources and you end up supporting a few Gbps, not too much compared with other options 14:40:02 danpb: a couple of your specs are super close, i only had some minor nits 14:40:18 thanks russellb 14:40:19 2 interfaces 1 net - https://review.openstack.org/#/c/97716/ 14:40:32 ijw: for VLAN trunking bp, we are looking to collapse all of them into https://review.openstack.org/#/c/100278/ 14:40:33 They're still warm from editing. 14:40:39 API extension for L2 gateway - https://review.openstack.org/#/c/100278/ 14:40:47 etc. 14:40:51 prio list from the wiki 14:40:55 s3wong: but that's about a gateway, not trunks 14:40:58 we can add to the list but let's try keep it tight 14:41:01 yeah, not sure if the l2 gw API is NFV specific 14:41:03 sgordon: yeah, that is the one 14:41:07 alank35, it's not tbh 14:41:11 Spec submitted for PCIe NUMA scheduling today. 14:41:24 i think the one ijw refered to was multi vnic per VM per neutron net 14:41:33 #topic blueprints 14:41:34 alank35, yes that is the first one i linked above 14:41:37 thanks russellb 14:41:38 2 interfaces 1 net - https://review.openstack.org/#/c/97716/ 14:41:43 russellb: bit late with that topic ;) 14:41:48 we kinda already moved on to that topic yeah :) 14:41:59 just syncing 14:42:26 So yes, https://review.openstack.org/#/c/97714/ simply proposes that you can ask for and identify a VLAN trunk, says nothing about breaking them apart 14:42:48 It's a very very trivial way of making this work but one that all plugins can support (merely by saying 'I don't make VLAN trunks' if necessary) 14:43:25 ijw: Can you map these to the ETSI-NFV use cases? 14:43:40 https://review.openstack.org/#/c/97715/ is basically a way for a port to say 'I don't have my own address' - with knock on implications for spoof and security grouping 14:43:56 adrian-hoban: Again, no, not really, they're very concrete and the use cases are very abstract 14:44:27 You can implement ETSI cases without them with suitable VNFs; and you can find that with specific devices you can't implement anything without them. 14:44:37 ijw: The api design of yours is too simplistic? It doesn't accomodate other use cases 14:44:39 +1 ijw 14:44:54 yamahata: can you be specific? 14:45:06 +1 14:45:07 ijw: as for 97715, neutron has already portsecurity extension to disable firewall etc. 14:45:20 yamahata: but you can't make a port that explicitly has no address 14:45:54 ijw: Right. I'm saying that we should split unfirewall and unaddress. 14:46:00 not by single switch. 14:46:16 besides the ETSI NFV use cases, it is worth going through the ETSI NFV architectural framework document 14:46:21 yamahata: Now, I absolutely wasn't saying it's the only way to turn off firewalling, just that it's not possible to firewall an unaddressed interface 14:46:23 portsecurity for unfirewall and something for unaddressed. 14:46:40 yamahata: +1 14:47:01 So yes, portsecurity remains for addressed interfaces with firewalling needs; unaddressed interfaces have it off just because there's no meaningful thing you can implement for them 14:47:43 ijw: agree that unaddressed means unfirewalled. 14:47:59 Please don't take that BP as saying 'this is the one true way to disable firewalls' - it is actually trying to say 'this is a case where firewalls must be off' 14:48:05 mmm so is there still a concern yamahata 14:48:15 ijw: I think what yamahata said is that unaddressed interfaces bp should be separated from unfirewalled 14:48:17 or has ijw explained the intent? 14:48:54 ijw: otherwise reviewers can say "there is already a bp for unfirewalled interfaces" 14:49:02 s3wong: right. 14:49:05 s3wong, sgordon: I believe yamahata is addressing the case where you have an addressed interface with firewalling needs, which isn't supposed to overlap with what I'm proposing. If we're all clear that that's OK then could you reread the BP in that light? 14:49:20 ijw, right - i am not sure i see the issue 14:49:31 ijw, there is nothing to separate out - they are already separate 14:49:36 (and if it needs clarification because people are misunderstanding it then comments, please 14:49:46 ijw, it's just an implication of using the functionality in yours that the firewall will be disabled 14:50:13 seems like we might need to take this to the review though :) 14:50:48 OK - to the review, people. I promise I'll edit it this evening if you get your comments in 14:50:51 sgordon: agreed, we should comment on review 14:51:11 (PST, for the temporally challenged) 14:51:35 russellb, should we move on to the last topic in the etherpad? 14:51:44 NFV team meet-up in Paris (https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 )? 14:51:44 Some folks seem to be interested (http://lists.openstack.org/pipermail/openstack-dev/2014-June/037608.html ) 14:52:00 Russell's getting old, keeps nodding off in the corner there 14:52:18 will not make it to Paris 14:52:30 would be better if the meetup is in NorthAmerica 14:52:41 #topic open discussion 14:52:44 the Nova meetup is in Portland, OR 14:52:48 Yeah, I don't think I would be able to make it to Europe 14:53:07 alank35: I was going to say we can wait until the K-Summit, but realized that that Summit happens to also be in Paris :-) 14:53:07 the question was, is it worth of interest to run another meetup in Europe, before the NA one ? 14:53:08 alank35, neither 14:53:27 yep, 14:53:40 and it's in just a few weeks 14:53:45 no way i could make it i think 14:53:49 Well, if we run a meetup what are we going to do at it, let's start there? 14:53:58 i'll be at the nova one though for sure 14:54:08 +1 ijw, so far i dont see much substance 14:54:12 ijw, at that point in the cycle we would hope to be well under way on coding 14:54:15 Again, running up a list of changes for j.3 is all well and good but to get them approved they will have to be persuasive and relatively easy to implement 14:54:16 so unless thats the aim... 14:54:25 the problem is not not all people can attend the Nova one in Portland, OR 14:54:26 :) 14:54:27 so until its nailed down, nfv meetup may be premature imho..... 14:54:43 is /that/ 14:54:54 bauzas: you should ask to go :) 14:54:57 And if we *are* all in the middle of coding then wandering off for a few days for a meetup might not be ideal... 14:55:18 russellb: I have my own personal duty :) 14:55:41 Not quite sure where people are, but we might be able to manage an ad hoc one near a concentration of people. I know Alan and Adrian make it over to the bay area occasionally 14:55:43 bauzas: especially for those focusing on Neutron :-) 14:56:53 +1 ijw, but i am on a plane so often these days it can be in "Hawaii" and i would definitely make time 14:57:04 it's settled then 14:57:07 If it's in Hawaii then so will I ;) 14:57:08 nfv meetup in hawaii 14:57:09 it's settled to be in Hawaii? 14:57:11 works for me 14:57:14 ;p 14:57:16 +1 14:57:28 You know, that's the closest we've had to a consensus all day. 14:57:29 i jest 14:57:38 ijw: :) 14:57:43 i agree with ijw and alank35 14:57:47 unless someone has a concrete proposal 14:58:05 no meetup this cycle? 14:58:08 of what to do at said meetup it's going to be hard to see people making time 14:58:16 Well, all I'll say is that if you find yourselves in the south bay, find me and we shall drink much beer 14:58:35 sounds reasonable 14:58:40 i am going to be there for the openstack design book sprint in early july 14:58:44 but that is another story 14:58:45 #agree no NFV specific meetup for Juno cycle, but ijw is offering beers in the bay area 14:58:46 :) 14:58:55 Works for me ;) 14:59:18 so we're at time as well 14:59:20 but... 14:59:22 If it works for some people to get together then great, but I think we need to focus on agreeing the priority and executing... 14:59:25 reviews, reviews, reviews 14:59:27 +1 will definitely come to the bay just for that 14:59:31 * russellb will review more this week! 14:59:32 both designs and code is starting to come as well 14:59:43 Sounds like ijw is buying :-) 14:59:47 nova stuff at least 14:59:51 adrian-hoban: stick your NFV/SRIOV use case together and anything of a similar nature, that will help with priorities 14:59:57 dont be disparaged, +1s and -1s are just as valuable for indicating things are heading in the right direction 15:00:04 core reviewers do notice your feedback 15:00:14 +1 to what sgordon said 15:00:26 hugely helpful to have input on these things 15:00:34 ok out of time 15:00:35 thanks! 15:00:36 #endmeeting