14:03:41 <russellb> #startmeeting nfv
14:03:42 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:45 <openstack> The meeting name has been set to 'nfv'
14:03:48 <bauzas> \o
14:03:50 <heyongli> hello
14:03:51 <russellb> hello!  who's around to talk NFV?
14:03:52 <nijaba> o/
14:03:54 <danpb> hi
14:03:55 <adrian-hoban> Hi
14:03:55 <s3wong> here
14:03:56 <yamahata> hi
14:03:57 <cloudon> hi
14:03:58 <sean-k-mooney> o/
14:03:59 <radek> Hi there !
14:04:10 <pczesno> hi
14:04:18 <sgordon_> yo!
14:04:19 <smazziotta> o/
14:04:25 <russellb> #link https://wiki.openstack.org/w/index.php?title=Meetings/NFV
14:04:28 <russellb> agenda on the etherpad:
14:04:49 <russellb> #link https://etherpad.openstack.org/p/nfv-meeting-agenda
14:04:59 <russellb> #topic review action items
14:05:09 <sgordon> so, infra
14:05:13 <russellb> cdub not here so we'll skip his
14:05:15 <sgordon> no cdub
14:05:15 <russellb> bauzas: o/
14:05:24 <bauzas> russellb: sure
14:05:35 <bauzas> russellb: so, I made a proposal
14:05:40 * russellb bauzas to make gerrit dashboard
14:05:42 <russellb> for context
14:05:54 <russellb> bauzas: have a link?
14:05:58 <bauzas> russellb: the idea is to make use of Gerrit for having a dashboard of all blueprints and patches
14:06:09 <bauzas> https://review.openstack.org/100559
14:06:23 <russellb> #link http://lists.openstack.org/pipermail/openstack-dev/2014-June/037941.html
14:06:25 <sgordon> im a little concerned about the invasiveness of having to add a tag to every commit
14:06:29 <russellb> #link https://review.openstack.org/100559
14:06:37 <russellb> yeah, i think we should avoid going that route
14:06:40 <sgordon> mainly an issue for the existing ones of course which will get sent for a loop
14:06:40 <bauzas> that's based on a new tool gerrit-dash-creator
14:06:55 <bauzas> sgordon: I do understand the problem
14:07:14 <bauzas> sgordon: we only need to find a way to discriminate all the NFV patches from the other ones
14:07:17 <russellb> or patches from people not necessarily in this group
14:07:36 <russellb> what if we maintain a list of gerrit topics in dash creator?
14:07:38 <sgordon> russellb, right
14:07:52 <bauzas> that's possible, but that will increase the query
14:07:55 <russellb> yes
14:08:01 <russellb> will be pretty big ...
14:08:10 <bauzas> and will require to shorten the url each time we add a new change
14:08:12 <russellb> but at least, in theory, you do an update once per blueprint we're tracking
14:08:16 <russellb> oh right
14:08:26 <russellb> the short url isn't static ...
14:08:30 <cgoncalves> hi all
14:08:35 <bauzas> russellb: right
14:08:36 <russellb> can link to it from our wiki page, and update that link
14:08:39 <russellb> i suppose.
14:08:46 <bauzas> that's possible
14:09:00 <bauzas> but that requires to vote on each change
14:09:01 <radek> patch subjects should be short by definition and adding some prefix make even less space for text
14:09:22 <bauzas> for each new blueprint, we have to issue a new side patch for gerrit-dash-creator
14:09:28 <sgordon> radek, the tag doesnt go in the subject
14:09:30 <bauzas> in order to update nfv.dash
14:09:47 <sgordon> mmm
14:09:51 <radek> ahhh ok so it change a lot and makes sense for me too
14:10:12 <russellb> really wish you could tag reviews in gerrit, without updating patches
14:10:21 <russellb> of course, non-existant gerrit features aren't helpful here :)
14:10:27 <sgordon> 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 <bauzas> russellb: labels are here for that, but that means it would create a new column
14:10:52 <sgordon> i think that is ok, no?
14:10:54 <russellb> new column in gerrit?
14:11:01 <ijw> 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 <sgordon> ijw, exactly
14:11:13 <russellb> ijw: yep
14:11:20 <sgordon> ijw, and also may be annoyed if someone tags it for them
14:11:28 <russellb> i would be
14:11:32 <russellb> (annoyed)
14:11:37 <sgordon> ijw, that's why i dont like that approach, even if the alternatives mean more work on our part
14:11:40 <ijw> I was certainly surprised mine had been tagged...
14:11:50 <bauzas> Gerrit now allows that
14:11:50 <ijw> But it's our problem, so such is life.
14:12:05 <sgordon> bauzas, allows?
14:12:09 <russellb> bauzas: can you clarify what gerrit allows?
14:12:31 <bauzas> ijw: I mean, now anyone can change a commit msg
14:12:41 <russellb> that was allowed before
14:12:45 <russellb> you just push an update to the review
14:12:48 <sgordon> yeah
14:12:49 <ijw> Yes - true, but if we don't get to a BP till it's accepted then what?
14:12:53 <bauzas> right, but not in the interface :)
14:13:17 <russellb> bauzas: ah..
14:13:25 <ijw> Better if you extracted the specs, bps or whatever from a wiki page and used that list
14:13:29 <sgordon> ijw, we celebrate that it was accepted and morn the fact that we cant track it automatically
14:13:55 <sgordon> ijw, right - i guess the missing bit is how to do that *and* build the status updates in automatically somewhere
14:14:05 <bauzas> ijw: the alternative is to update https://review.openstack.org/100559 with all the topic names for the blueprints
14:14:12 <sgordon> i mean we have the list on the wiki today, incl. statuses, but updating them is going to be v. manual
14:14:20 <russellb> bauzas: that's what i prefer right now i'm afraid
14:14:38 <russellb> a gerrit dashboard would be super helpful to me as a reviewer, too
14:14:47 <russellb> so i can go target NFV related spec and code reviews
14:14:53 <ijw> 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 <russellb> ijw: which pointless reviews?
14:15:22 <sgordon> russellb, when the patch gets bumped for the tag add
14:15:27 <russellb> yes
14:15:31 <alank35> +1 we sure do have better things to be spending time on,
14:15:32 <sgordon> russellb, bauzas was saying this doesnt count as a trivial
14:15:50 <sgordon> yeah, i think that's agreement that the tag approach is a no go
14:15:54 <russellb> yes
14:16:04 <russellb> how about trying a list of gerrit topics in the dash creator for now
14:16:10 <ijw> 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 <bauzas> ijw: right, that's the alternative
14:16:25 <sgordon> ijw, correct
14:16:28 <russellb> each gerrit topic, which should cover several patches
14:16:35 <russellb> an update to the dash per blueprint, vs per patch
14:16:39 <bauzas> ok, I can do that
14:16:48 <sgordon> 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 <russellb> bauzas: willing to do a first cut on that?
14:16:55 <sgordon> means topic/bp addition remains manual
14:17:09 <bauzas> that only requires to send a git-review for each update, but that's life
14:17:15 <russellb> bauzas: *nods*
14:17:27 <russellb> i'd just script the first cut at it
14:17:37 <bauzas> russellb: yey, we can try
14:17:42 <danpb> 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 <russellb> parse the wiki page table for blueprint URLs, and use topics of "bp/<blueprint>"
14:17:53 <russellb> danpb: or that.
14:18:10 <russellb> scrape wiki for blueprints, scrape blueprints for reviews, scrape reviews for status, generate page :)
14:18:13 <danpb> 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 <sgordon> danpb, that is pretty tempting to me tbh
14:18:42 <danpb> https://xkcd.com/208/
14:18:53 <sgordon> danpb, no problem that cant be solved by adding more bash right?
14:18:54 <russellb> sgordon: yeah
14:18:59 <russellb> bauzas: what do you think of that idea?
14:19:03 <danpb> sgordon: perl please ;-P
14:19:16 <ijw> Go for it, people.
14:19:17 <bauzas> russellb: that's sexy
14:19:22 <sgordon> ok
14:19:25 <russellb> bauzas: willing to write it?  :)
14:19:29 <ijw> danpb: you luddite. ;)
14:19:39 <bauzas> russellb: yup
14:19:42 <russellb> bauzas: awesome!
14:19:56 * ijw <- JAPH
14:20:12 <russellb> #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 <sgordon> 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 <russellb> yeah...
14:20:25 <russellb> scrape blueprint whiteboard for list of reviews
14:20:27 <sgordon> (launchpadlib's support for blueprints is....interesting)
14:20:27 <russellb> that'll be fun.
14:20:32 <russellb> and by fun i mean *headdesk*
14:20:40 <sgordon> ok
14:20:44 <russellb> next topic :)
14:20:53 <sgordon> 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 <sgordon> nijaba, i believe added a desc
14:21:04 <russellb> wiki page has been updated!
14:21:06 <nijaba> done: https://wiki.openstack.org/wiki/Teams/NFV#What_is_NFV.3F
14:21:14 <ijw> Yeah - I missed last weeks' meeting but I think we have an issue with the use cases
14:21:15 <russellb> sounds good to me, much appreciated
14:21:24 <sgordon> #link https://wiki.openstack.org/wiki/Meetings/NFV#What_is_NFV.3F
14:21:24 <nijaba> it's a first version, feel free to update!
14:21:41 <alank35> ijw, whats your concern?
14:21:42 <sgordon> +1
14:21:44 <ijw> 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 <smazziotta> +1
14:21:58 <adrian-hoban> I added ETSI-NFV use case descriptions and a first cut of mappings to blueprints
14:22:05 <sgordon> ijw, right - primarily the ETSI ones right
14:22:35 <sgordon> we need to drill into them at the same time
14:22:45 <adrian-hoban> A contribution from Calum Loudon has mapped blueprints to a Session Border Controller
14:22:52 <sgordon> yes
14:22:55 <sgordon> i added that to the wiki
14:22:55 <ijw> 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 <cloudon> sgordon: thanks for doing that
14:23:20 <alank35> adrian, where is that contribution from Calum?
14:23:23 <ijw> 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 <sgordon> well, i think there is a reality that there is a core subset that are going to apply to most
14:23:38 <sgordon> alank35, https://wiki.openstack.org/wiki/Meetings/NFV#Contributed_Use_Cases
14:23:40 <cloudon> alank35: ML, now on wiki coiurtesy sgordon
14:23:40 <sgordon> #link https://wiki.openstack.org/wiki/Meetings/NFV#Contributed_Use_Cases
14:23:52 <ijw> sgordon: true, but e.g. the scheduler is useful to most but essential to none.
14:23:59 <alank35> cheers steve
14:24:03 <sgordon> ijw, agree
14:24:19 <sgordon> ijw, mainly wondering if i will see many/any that dont want sriov or dpdk for example
14:24:34 <ijw> 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 <cloudon> sgordon: I have some control plane examples which don't
14:24:55 <sgordon> cloudon, would be great to share - i really liked the way you structured the first one
14:25:12 <cloudon> Was the Session border controller example the sort of specifics people are looking for?
14:25:26 <adrian-hoban> 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 <sgordon> adrian-hoban, right
14:25:48 <sgordon> adrian-hoban, i still think it's useful for mapping the two worlds
14:25:55 <alank35> +1 ijw on service chains
14:26:01 <sgordon> adrian-hoban, need to put more specific examples into those categories
14:26:08 <s3wong> ijw: how would NFV guys define service chaining?
14:26:26 <alank35> i think that sbc is perahps implementation specific
14:26:45 <sgordon> cloudon, i think so - i think we need to come up with a better way to highlight the mapping to bps
14:27:03 <sgordon> cloudon, perhaps the way adrian-hoban formatted it into the table for the (admittedly broad) etsi ones for example
14:27:23 <sgordon> 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 <ijw> 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 <cloudon> sgordon: +1
14:28:21 <ijw> 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 <sgordon> ijw, completely agree
14:28:46 <ijw> A middle layer of mapping, if you like
14:28:57 <cloudon> ijw, sgordon: I'll contribute concrete example for ETSI #5
14:29:11 <ijw> Simple answer is probably if we all have a go at one.
14:29:18 <sgordon> #action cloudon to provide a concrete example for ETSI # 5
14:29:29 <alank35> 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 <alank35> from this point you can ensure on boarding and deployment and provisioning of NFV in Openstack
14:30:01 <ijw> alank35: well, we have some BPs up, one of which I see Racha took on
14:30:26 <sgordon> i do think the priority list of 3
14:30:34 <ijw> 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 <sgordon> covers some of the real burning "we cant work without this" items
14:30:35 <alank35> yeh, not sure where that will land
14:30:50 <sgordon> ijw, right
14:30:57 <ijw> Well, j.2 is 4 weeks, we can target that and get the short term stuff up
14:31:19 <sgordon> ijw, so there is really two factors - how close/realistic things are for juno and how important they are
14:31:21 <radek> 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 <sgordon> sriov for example i notice the design got approved yesterday
14:31:59 <radek> sgordon: sriov in nova project ?
14:32:00 <ijw> 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 <sgordon> radek, yes
14:32:10 <sgordon> ijw, yep
14:32:49 <adrian-hoban_> 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 <sgordon> 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 <alank35> ijw would agree, i think we will waste time focusing on usecases that are perhaps not too vital in the end
14:33:20 <ijw> 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 <ggarcia> adrian_hoban_ +1
14:33:34 <radek> SRIOV is kind of base which will be needed in other projects components to and it's close tied to performance
14:33:36 <alank35> and most likely given what may end up happening is that we fullfill usecases for a limited number of vendors implementation
14:33:41 <russellb> sgordon: that date is aug 21
14:33:41 <sgordon> ijw, i think review cycles from people who understand how they use these things are crucial
14:33:45 <russellb> https://wiki.openstack.org/wiki/Juno_Release_Schedule
14:33:49 <sgordon> ijw, and an area where this group can help
14:34:09 <ijw> 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 <sgordon> 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 <sgordon> russellb, thanks
14:34:32 <alank35> ijw; sure can help on the review
14:34:36 <bauzas> is SRIOV requiring some PCI refactoring in Nova?
14:34:37 <sgordon> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
14:34:52 <sgordon> bauzas, https://review.openstack.org/#/c/86606/
14:34:57 <ijw> 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 <adrian-hoban_> ijw: I think PCIe passthrough and/or SR-IOV are essential if your performance requirements warrant it
14:35:25 <ijw> adrian-hoban_: There's more than one way to skin a cat: DPDK, Contrail, Snabb...
14:35:48 <ijw> Point being it's significant, granted, but not a blocker.
14:35:50 <cloudon> ijw: +1
14:36:00 <radek> bauzas: not sure if SRIOV is fully supported by libvirtd and nova changes will be required too
14:36:12 <sgordon> radek, libvirt has supported it for years afaik
14:36:14 <bauzas> sgordon: thanks
14:36:30 <sgordon> radek, problem has been exposing it up the nova/neutron stack
14:36:32 <ijw> 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 <ggarcia> ijw, adrian_hoban_ : Well, the alternative is the vSwitch, which consumes extra CPU and memory resources
14:36:40 <bauzas> sgordon: my concern is that PCI passthru in Nova requires a little refactoring
14:36:41 <ijw> s/the/an/
14:37:04 <sgordon> bauzas, the existing impl. or the sriov additions?
14:37:14 <bauzas> nah, the exisiting impl
14:37:15 <radek> 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 <sgordon> bauzas, tbh i can only suggest to get involved in the design/discussion
14:37:29 <bauzas> sgordon: will do
14:37:35 <ijw> 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 <sgordon> radek, i suspect you mean at the PCIe lane topology level - which is really additional
14:37:44 <radek> sgordon: anyway this is very detaild discussion out of today scope
14:37:48 <sgordon> radek, it has supporting for passing through VFs today
14:38:15 <sgordon> ok
14:38:26 <sgordon> so the action item here appears to be moar reviews in general
14:38:27 <ijw> 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 <sgordon> right so spec reviews but also code reviews will start coming for some of these
14:38:55 <adrian-hoban> 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 <russellb> and helped get the SR-IOV one approved, yay
14:39:49 <ggarcia> 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 <russellb> danpb: a couple of your specs are super close, i only had some minor nits
14:40:18 <heyongli> thanks russellb
14:40:19 <sgordon> 2 interfaces 1 net - https://review.openstack.org/#/c/97716/
14:40:32 <s3wong> ijw: for VLAN trunking bp, we are looking to collapse all of them into https://review.openstack.org/#/c/100278/
14:40:33 <ijw> They're still warm from editing.
14:40:39 <sgordon> API extension for L2 gateway - https://review.openstack.org/#/c/100278/
14:40:47 <sgordon> etc.
14:40:51 <sgordon> prio list from the wiki
14:40:55 <ijw> s3wong: but that's about a gateway, not trunks
14:40:58 <sgordon> we can add to the list but let's try keep it tight
14:41:01 <alank35> yeah, not sure if the l2 gw API is NFV specific
14:41:03 <s3wong> sgordon: yeah, that is the one
14:41:07 <sgordon> alank35, it's not tbh
14:41:11 <adrian-hoban> Spec submitted for PCIe NUMA scheduling today.
14:41:24 <alank35> i think the one ijw refered to was multi vnic per VM per neutron net
14:41:33 <russellb> #topic blueprints
14:41:34 <sgordon> alank35, yes that is the first one i linked above
14:41:37 <sgordon> <heyongli> thanks russellb
14:41:38 <sgordon> <sgordon> 2 interfaces 1 net - https://review.openstack.org/#/c/97716/
14:41:43 <ijw> russellb: bit late with that topic ;)
14:41:48 <russellb> we kinda already moved on to that topic yeah :)
14:41:59 <russellb> just syncing
14:42:26 <ijw> 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 <ijw> 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 <adrian-hoban> ijw: Can you map these to the ETSI-NFV use cases?
14:43:40 <ijw> 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 <ijw> adrian-hoban: Again, no, not really, they're very concrete and the use cases are very abstract
14:44:27 <ijw> 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 <yamahata> ijw: The api design of yours is too simplistic? It doesn't accomodate other use cases
14:44:39 <alank35> +1 ijw
14:44:54 <ijw> yamahata: can you be specific?
14:45:06 <sgordon> +1
14:45:07 <yamahata> ijw: as for 97715, neutron has already portsecurity extension to disable firewall etc.
14:45:20 <ijw> yamahata: but you can't make a port that explicitly has no address
14:45:54 <yamahata> ijw: Right. I'm saying that we should split unfirewall and unaddress.
14:46:00 <yamahata> not by single switch.
14:46:16 <ramki> besides the ETSI NFV use cases, it is worth going through the ETSI NFV architectural framework document
14:46:21 <ijw> 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 <yamahata> portsecurity for unfirewall and something for unaddressed.
14:46:40 <s3wong> yamahata: +1
14:47:01 <ijw> 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 <yamahata> ijw: agree that unaddressed means unfirewalled.
14:47:59 <ijw> 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 <sgordon> mmm so is there still a concern yamahata
14:48:15 <s3wong> ijw: I think what yamahata said is that unaddressed interfaces bp should be separated from unfirewalled
14:48:17 <sgordon> or has ijw explained the intent?
14:48:54 <s3wong> ijw: otherwise reviewers can say "there is already a bp for unfirewalled interfaces"
14:49:02 <yamahata> s3wong: right.
14:49:05 <ijw> 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 <sgordon> ijw, right - i am not sure i see the issue
14:49:31 <sgordon> ijw, there is nothing to separate out - they are already separate
14:49:36 <ijw> (and if it needs clarification because people are misunderstanding it then comments, please
14:49:46 <sgordon> ijw, it's just an implication of using the functionality in yours that the firewall will be disabled
14:50:13 <sgordon> seems like we might need to take this to the review though :)
14:50:48 <ijw> OK - to the review, people.  I promise I'll edit it this evening if you get your comments in
14:50:51 <s3wong> sgordon: agreed, we should comment on review
14:51:11 <ijw> (PST, for the temporally challenged)
14:51:35 <sgordon> russellb, should we move on to the last topic in the etherpad?
14:51:44 <sgordon> NFV team meet-up in Paris (https://wiki.openstack.org/wiki/Sprints/ParisJuno2014 )?
14:51:44 <sgordon> Some folks seem to be interested (http://lists.openstack.org/pipermail/openstack-dev/2014-June/037608.html )
14:52:00 <ijw> Russell's getting old, keeps nodding off in the corner there
14:52:18 <alank35> will not make it to Paris
14:52:30 <alank35> would be better if the meetup is in NorthAmerica
14:52:41 <russellb> #topic open discussion
14:52:44 <bauzas> the Nova meetup is in Portland, OR
14:52:48 <ijw> Yeah, I don't think I would be able to make it to Europe
14:53:07 <s3wong> 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 <bauzas> the question was, is it worth of interest to run another meetup in Europe, before the NA one ?
14:53:08 <sgordon> alank35, neither
14:53:27 <alank35> yep,
14:53:40 <russellb> and it's in just a few weeks
14:53:45 <russellb> no way i could make it i think
14:53:49 <ijw> Well, if we run a meetup what are we going to do at it, let's start there?
14:53:58 <russellb> i'll be at the nova one though for sure
14:54:08 <alank35> +1 ijw, so far i dont see much substance
14:54:12 <sgordon> ijw, at that point in the cycle we would hope to be well under way on coding
14:54:15 <ijw> 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 <sgordon> so unless thats the aim...
14:54:25 <bauzas> the problem is not not all people can attend the Nova one in Portland, OR
14:54:26 <bauzas> :)
14:54:27 <alank35> so until its nailed down, nfv meetup may be premature imho.....
14:54:43 <bauzas> is /that/
14:54:54 <russellb> bauzas: you should ask to go :)
14:54:57 <ijw> 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 <bauzas> russellb: I have my own personal duty :)
14:55:41 <ijw> 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 <s3wong> bauzas: especially for those focusing on Neutron :-)
14:56:53 <alank35> +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 <sgordon> it's settled then
14:57:07 <ijw> If it's in Hawaii then so will I ;)
14:57:08 <sgordon> nfv meetup in hawaii
14:57:09 <russellb> it's settled to be in Hawaii?
14:57:11 <russellb> works for me
14:57:14 <sgordon> ;p
14:57:16 <nijaba> +1
14:57:28 <ijw> You know, that's the closest we've had to a consensus all day.
14:57:29 <sgordon> i jest
14:57:38 <russellb> ijw: :)
14:57:43 <sgordon> i agree with ijw and alank35
14:57:47 <sgordon> unless someone has a concrete proposal
14:58:05 <russellb> no meetup this cycle?
14:58:08 <sgordon> of what to do at said meetup it's going to be hard to see people making time
14:58:16 <ijw> 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 <bauzas> sounds reasonable
14:58:40 <sgordon> i am going to be there for the openstack design book sprint in early july
14:58:44 <sgordon> but that is another story
14:58:45 <russellb> #agree no NFV specific meetup for Juno cycle, but ijw is offering beers in the bay area
14:58:46 <russellb> :)
14:58:55 <ijw> Works for me ;)
14:59:18 <sgordon> so we're at time as well
14:59:20 <sgordon> but...
14:59:22 <adrian-hoban> 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 <sgordon> reviews, reviews, reviews
14:59:27 <alank35> +1 will definitely come to the bay just for that
14:59:31 * russellb will review more this week!
14:59:32 <sgordon> both designs and code is starting to come as well
14:59:43 <adrian-hoban> Sounds like ijw is buying :-)
14:59:47 <russellb> nova stuff at least
14:59:51 <ijw> adrian-hoban: stick your NFV/SRIOV use case together and anything of a similar nature, that will help with priorities
14:59:57 <sgordon> dont be disparaged, +1s and -1s are just as valuable for indicating things are heading in the right direction
15:00:04 <sgordon> core reviewers do notice your feedback
15:00:14 <russellb> +1 to what sgordon said
15:00:26 <russellb> hugely helpful to have input on these things
15:00:34 <russellb> ok out of time
15:00:35 <russellb> thanks!
15:00:36 <russellb> #endmeeting