18:00:58 <tbachman> #startmeeting gbp_status_arch
18:00:58 <odl_meetbot> Meeting started Fri Feb 20 18:00:58 2015 UTC.  The chair is tbachman. Information about MeetBot at http://ci.openstack.org/meetbot.html.
18:00:58 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:58 <odl_meetbot> The meeting name has been set to 'gbp_status_arch'
18:01:03 <tbachman> #topic agenda
18:01:24 <alagalah> https://meetings.webex.com/collabs/meetings/join?uuid=M4PO9GTADM5ZZWKPF30D5WC98O-9VIB
18:01:30 <alagalah> #info Meeting is here: https://meetings.webex.com/collabs/meetings/join?uuid=M4PO9GTADM5ZZWKPF30D5WC98O-9VIB
18:01:46 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000940.html Email describing today’s agenda
18:01:53 <alagalah> #info we changed WebEx (and this is reflected on the wiki, the odl meeting page etc) due to there being fraud on the last webex
18:02:26 <tbachman> #link https://meetings.opendaylight.org/opendaylight-group-policy/2015/gbp_status_arch/opendaylight-group-policy-gbp_status_arch.2015-02-13-18.00.html last week’s meeting minutes
18:03:04 <tbachman> #topic SFC Update
18:03:59 <tbachman> #chair alagalah
18:03:59 <odl_meetbot> Current chairs: alagalah tbachman
18:04:02 <alagalah> #undo
18:04:02 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x19b35d0>
18:04:14 <alagalah> #topic Agenda
18:04:22 <alagalah> #link Agenda: https://wiki.opendaylight.org/view/Group_Policy:Sub-Groups:STATUS#Team_Meeting
18:04:31 <alagalah> #topic SFC Update
18:04:45 * dbainbri cooling his jets
18:07:03 <tbachman> #link https://git.opendaylight.org/gerrit/#/c/15521/ Initial gerrit for GBP SFC integration
18:07:17 <tbachman> #link https://git.opendaylight.org/gerrit/#/c/15255 expansion of GBP SFC integration
18:08:56 <dbainbri> so the mode of operation is a model change in GBP triggers an API call to SFC?
18:09:34 <tbachman> dbainbri: ack
18:10:12 <dbainbri> tbachman: mèsi
18:10:27 <tbachman> merci?
18:10:31 <tbachman> or messy
18:11:07 <tbachman> #info tbachman is working with repenno on integration the two pieces. Still some details as to whether to keep the existing static method or convert to an RPC
18:11:12 <dbainbri> Haitian Creole: for thank you, their version of merci.
18:11:19 <tbachman> ah :)
18:11:51 <tbachman> #info tbachman invites anyone interested to reach out to himself or reinaldo
18:11:59 <alagalah> #topic Code Merges
18:13:59 <alagalah> #link https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=summary
18:17:56 <tbachman> #link https://bugs.opendaylight.org/show_bug.cgi?id=2689 Bug: cast exception when serialiing L3Address from groupbasedpolicy policy.yang
18:18:33 <tbachman> #link https://bugs.opendaylight.org/show_bug.cgi?id=2657 Bug: Flow present in configuration data store but not operational when running groupbasedpolicy POC test
18:18:57 <tbachman> #info note that 2689 is fixed with gerrit: https://git.opendaylight.org/gerrit/#/c/15558/1
18:19:14 <alagalah> #info abhijitkumbhare suggests that we CC: groupbasedpolicy-XXX (dev?) on bugs so we can track
18:19:29 <alagalah> #action tbachman to CC: groupbasedpolicy-XXX on bugs
18:19:57 <tbachman> #topic Trello Board
18:20:14 <tbachman> #link https://trello.com/b/yc0xHFlv/opendaylight-groupbasedpolicy-lithium Group Based Policy Lithium Trello Board
18:21:03 <tbachman> #info alagalah went through trello, removed duplicates, cleaned things up, added new cards
18:21:21 <tbachman> #info cards at top of the category are higher priority than those lower in the category
18:21:36 <tbachman> #info alagalah says the super-cala-fragalistic important is the best list for folks to pick cards up from
18:22:40 <tbachman> #info The ‘Create SFC + GBP Use case’ card has been addded, moved to ‘done since last meeting’
18:23:11 <tbachman> #info alagalah added the port-name field to the endpoint yang model, to help with openstack integration
18:23:36 <tbachman> #info Sanjay asks if we need the access switch name or IP, along with the port name
18:24:08 <tbachman> #info alagalah says he’s considering port-name to be more like a “locator”, as port-name may not support all the use cases
18:24:46 <tbachman> #info alagalah asks what community would want as a generic way of providing this information on an endpoint
18:25:54 <tbachman> #info Sanjay says he feels that having a node,port-name is the best solution — with virtualized switches, with different ways of getting to the switch, might be best
18:26:09 <tbachman> #info alagalah says we need to be generic enough — e.g. a lambda, or what have you
18:26:23 <tbachman> #info Sanjay says it can just be a string
18:28:17 <tbachman> #info alagalah asks if Sanjay can pick up this trello card
18:28:20 <tbachman> #info Sanjay says yes
18:29:14 <tbachman> #info Meenakshi asks if it can also take a mask
18:29:56 <tbachman> #info alagalah says he’s aware of the use case; knows that it’s nice if an EP can be a CIDR block for “grey-list” access; that will be a separate work item (multi-EPG work)
18:31:48 <tbachman> #info alagalah created a new category for “Testing”
18:32:52 <tbachman> #info alagalah has verified that multi-tenancy works, using POC
18:33:17 <tbachman> #info alagalah says there’s a minor fix needed for intra-EPG policy resolution — will submit a gerrit
18:33:59 <tbachman> #info alagalah has a working copy of the multi-EPG operation, but needs some additional work; will submit when that’s done
18:34:20 <tbachman> #info neutron API mapping is being covered by martin_sunal
18:35:16 <tbachman> #info martin_sunal is hoping to provide a gerrit this weekend that provides an initial mapping
18:36:48 <tbachman> #info yapeng is looking into adding multi-renderer support
18:37:10 <tbachman> #info edwarnicke asks if this work effort is to handle things where renderers don’t step on each other
18:38:14 * edwarnicke was once, long ago a CCIE... and thus his fingers still remember administrative distance ;)
18:38:17 <tbachman> #info alagalah says there are a few things here — we first need to add support for being able to have multiple renderers loaded (currently not supported); there are other levels of supporting this
18:38:42 * tbachman tries to keep administrative distance from administrative things
18:39:28 <tbachman> #info alagalah says there’s another piece where a rendere can be guaranteed a single-writer, optionally a single writer, or never guaranteed as a single writer
18:40:36 <abhijitkumbhare> tbachman - should it be " guaranteed to be never a single writer" (last #info)
18:41:04 <abhijitkumbhare> or  " guaranteed to be never a writer"
18:41:15 <tbachman> abhijitkumbhare: thx!
18:41:18 <tbachman> #undo
18:41:18 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1bacb10>
18:41:43 <tbachman> #info alagalah says there’s another piece where a rendere can be guaranteed a single-writer, optionally a single writer, or guaranteed to never be the single writer
18:41:48 <tbachman> abhijitkumbhare: better? ^^^^
18:42:05 <abhijitkumbhare> yes tbachman
18:42:09 <tbachman> abhijitkumbhare: thx! :)
18:42:12 <abhijitkumbhare> thx :)
18:42:19 <tbachman> np!
18:43:15 <s3wong> without understanding too much on the intention / use case of multi-renderer, the ML2 model used by Neutron can be a reference
18:43:38 <tbachman> s3wong: that might be helpful!
18:43:43 <tbachman> we might have to tap your brain there
18:44:10 <s3wong> tbachman: sure, I just dropped out of the webex (in meeting now)
18:44:16 <tbachman> s3wong: ack
18:44:47 <tbachman> #info alagalah is looking into the FD/BD/Subnet selection to DP
18:44:50 <tbachman> #undo
18:44:50 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1bac990>
18:44:56 <tbachman> #info alagalah is looking into the FD/BD/Subnet selection to EP
18:45:28 <tbachman> #info alagalah says we should revamp the wiki a bit — wants it to be more useful to different audiences
18:45:39 <tbachman> #info for example, end-users, developers, architects, etc.
18:46:20 <tbachman> #info alagalah has a beta version, but needs a bit more work before making it the actual project home page
18:52:29 <tbachman> #info alagalah asks if yapeng can work on porting openstack API support to the generic endpoint
18:52:50 <tbachman> #info yapeng says since there’s already something released in openstack, we’ll need to address backwards-compatibility
18:53:44 <tbachman> #info alagalah asks if the URI used by OpenStack is in a separate file, or embeded in the code
18:54:18 <tbachman> #info yapeng says it’s embedded in the code; the fix for this is pretty quick/easy, but the harder part is addressing backwards compatibility
18:56:34 <s3wong> is Lithium working with OpenStack GBP Juno release a requirement? or can we just say we only work with Kilo?
18:57:31 <tbachman> s3wong: good question
18:58:08 <tbachman> s3wong: since there’s already something implemented in Juno, I think we have to interop with that with Lithium
18:58:57 <s3wong> tbachman: Lithium timeframe aligns very well with expected Kilo GBP release --- just something to consider
18:59:23 <tbachman> s3wong: ack. Is it wrong to consider interop’ing with both?
18:59:51 <s3wong> tbachman: in reality, only Lithium can work with anything from OpenStack GBP
19:00:37 <s3wong> tbachman: so the question is whether interop with Juno is important enough to hinder ODL GBP <-> OpenStack integration enhancement
19:01:59 <s3wong> tbachman: anyway, just want to bring up that if backward compatibility becomes an issue, we may want to consider just jump to Kilo
19:04:47 <tbachman> s3wong: no — thanks much!  We can definitely use some help there!
19:05:05 <tbachman> s3wong: I don’t think I have a good answer for you yet
19:05:20 <s3wong> tbachman: it's OK :-)
19:06:29 <tbachman> #link https://git.opendaylight.org/gerrit/#/c/9752/ original gerrit to create tunnels in GBP using OVSDB
19:16:53 <tbachman> #link https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000886.html email from mickey_spiegel describing multiple actions
19:17:17 <tbachman> #info alagalah says we can talk about the actions, but we’d need good definitions of what those are
19:17:59 <tbachman> #info mickey_spiegel says we need a well-known way, in terms of syntax, for things that are common
19:18:11 <tbachman> #info mickey_spiegel says things like allow are pretty straightforward
19:18:12 <s3wong> alagalah, tbachman, mickey_spiegel: how about mickey_spiegel's suggestion on basic classifier (L4 src/dst port)?
19:18:42 <tbachman> s3wong: yeah — I think these are under discussion
19:19:07 <tbachman> #info mickey_spiegel says that right now these items are populated in the operational data store by the openflow renderer
19:19:37 <tbachman> #info alagalah says we can do this as a “top-down”, where we define these across all renderers, or “bottom-up”, where each renderer provides the definitions
19:20:00 <tbachman> #info mickey_spiegel asks if we can have a common list of subject-features, and each renderer could list which ones it supports.
19:20:16 <tbachman> #info alagalah asks how we handle cases where a renderer can’t handle a given subject-feature
19:20:59 <s3wong> tbachman, alagalah: realistically, do we approve renderer that cannot match on L4 ports and can't do ALLOW (or conversely DENY)?
19:21:34 <tbachman> s3wong: that’s what’s being discussed (more generally)
19:21:47 <tbachman> #info s3wong asks if realistically, do we approve renderer that cannot match on L4 ports and can't do ALLOW (or conversely DENY)?
19:21:51 <s3wong> tbachman: sorry. not on webex :-)
19:21:58 <tbachman> s3wong: no worries
19:22:32 <tbachman> #info tbachman says one possibility is that something not supported by a renderer could result in the renderer reporting this to the exception repo, with the appropriate action taken
19:25:12 <tbachman> alagalah: https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000886.html
19:31:55 <tbachman> #action alagalah to follow up on mickey_spiegel’s email (https://lists.opendaylight.org/pipermail/groupbasedpolicy-dev/2015-February/000886.html) on best approach for how subject-features will be supported across renderers
19:44:50 <tbachman> #info edwarnicke is trying to chase down a resource for tempest testing
19:46:23 <tbachman> #endmeeting