14:30:11 <colindixon> #startmeeting Weekly Lithium IRC Sync
14:30:11 <odl_meetbot> Meeting started Wed Mar 25 14:30:11 2015 UTC.  The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html.
14:30:11 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:30:11 <odl_meetbot> The meeting name has been set to 'weekly_lithium_irc_sync'
14:30:20 <colindixon> #topic agenda bashing
14:30:22 <colindixon> #undo
14:30:22 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Topic object at 0x1bab510>
14:30:27 <colindixon> #topic roll call and agenda
14:30:43 <rovarga_> alagalah: man, I essentially have a single one since 8:30 :)
14:30:54 <rovarga_> alagalah: (e.g. 7 hours straight)
14:31:07 <colindixon> #link https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan#Cross_Project_Meetings agenda in it’s usual place
14:31:09 <regXboi> #info regXboi for NN
14:31:11 <alagalah> rovarga_: Long time no talk :)
14:31:16 <colindixon> #Info colindixon for TTP, Docs and TSC
14:31:21 <gzhao> ＃info gzhao for release
14:31:24 <ttkacik> #info ttkacik for Controllre
14:31:25 <fabiel> #info fabiel for Persistence Store Service
14:31:25 <hideyuki> #info Hideyuki for VTN
14:31:26 <regXboi> #info regXboi also for general gadflyness
14:31:26 <rovarga_> #info rovarga for yagntools
14:31:27 <alagalah> rovarga_: You can't call an "offsite" a meeting and expect me to keep a straight face
14:31:28 <ttkacik> #info ttkacik for Controller
14:31:29 <gzhao> #info gzhao for release
14:31:34 <alagalah> #info alagalah GBP
14:31:52 * regXboi would like to see alagalah try and keep a straight face on that provication :)
14:32:57 <colindixon> any other topics?
14:33:17 <alagalah> regXboi: :)
14:33:25 <LuisGomez> #info LuisGomez integration
14:33:52 <regXboi> colindixon: what the heck is going on in discuss?
14:34:02 <colindixon> regXboi? link?
14:34:08 * regXboi goes and digs
14:34:22 <tbachman> regXboi: you mean the DE:AD:BE:EF?
14:34:31 <regXboi> tbachman: yes
14:34:52 <regXboi> #link https://lists.opendaylight.org/pipermail/discuss/2015-March/004876.html the start of the thread
14:35:00 * regXboi isn't sure what it has mutated into now
14:35:00 <colindixon> regXboi: I haven’t followed it since last night
14:35:38 <abhijitkumbhare> #info abhijitkumbhare for OF plugin
14:35:49 <colindixon> #info colindixon wants to talk a bit about docs
14:35:53 <regXboi> colindixon: my reason for asking is that if we suddenly start changing what things like mac and ipv6 are stored as, I shudder to think what will happen
14:36:04 * tbachman nods
14:36:09 <Prem> #info Prem for VPNService
14:36:09 <regXboi> #info +1 to a docs discussion
14:36:28 <zxiiro> #info Thanh releng
14:36:58 <colindixon> #topic topics of general concern
14:37:01 <alagalah> regXboi: I got 4 emails in and I started hitting the roof and causing cubes to blowover my beanie-propeller was spinning so hard
14:37:20 <alagalah> colindixon: yes
14:37:50 <alagalah> colindixon: tbachman has found an issue that is with OFP and/or OFJ, he is filing a bug
14:38:04 <alagalah> http://pastebin.com/Mkag1pRn
14:38:06 <colindixon> #link https://lists.opendaylight.org/pipermail/discuss/2015-March/004876.html migrating to storing addresses in a canonical format
14:38:13 <colindixon> regXboi: want to take that away for 2-3 minutes
14:38:17 <colindixon> alagalah: you’re next
14:38:34 <alagalah> colindixon: Ok but if OFP/OFJ is hosed, that means a shed-load of people are blocked
14:38:35 <regXboi> colindixon: I think I can +1 the idea of storing items in IETF canonical format
14:38:44 <colindixon> regXboi: I can too
14:39:05 <regXboi> colindixon: where I get concerned is that it appears to be migrating away from "be conservative in what you send, liberal in what you accept"
14:39:41 <regXboi> in other words, I believe that something in the chain should be assuming that what has been received *isn't* necessarily canonical format and making the conversion
14:39:55 <regXboi> I question whether that should be at the md-sal/yang model
14:40:21 <colindixon> #info the basic issues is that the way we currently store most addresses allows for strings that are logically equal (de:ad::be:ef vs. DE:AD::BE:EF) but are not actually equal which can lead to bugs or at the very least lots of having to do canonicaliztion in every place we uses stuff
14:40:27 * tbachman is filing at least two, possibly 3 bugs
14:40:35 <regXboi> I sorta think that would be one of the jobs of the code that receives the value in question
14:40:39 <colindixon> regXboi: does that cover it?
14:40:43 <colindixon> can you #info other things?
14:40:48 <regXboi> sure
14:40:59 <abhijitkumbhare> alagalah tbachman - please send us the bugs info
14:41:06 <tbachman> abhijitkumbhare: will do!
14:41:08 <alagalah> abhijitkumbhare: They are coming in
14:41:14 <abhijitkumbhare> sure
14:41:15 <regXboi> #info regXboi is concerned that the conversation has migrated away from the principal of "be conservative in what you send, liberal in what you accept"
14:41:39 <regXboi> #info regXboi is further concerned that the conversion may be shoehorned into the md-sal/yang model
14:42:24 <regXboi> #info regXboi thinks that the best place for such conversion is the code that acts as the ODL entry point for the value in the first place
14:42:33 <regXboi> colindixon: there you go
14:42:35 <colindixon> regXboi: thanks!
14:42:52 <colindixon> alagalah, tbachman: can you summarize what’s going on?
14:43:03 <alagalah> Pastebin linked above and
14:43:04 * tbachman is in the process of filing said bugs
14:43:18 <tbachman> one is an exception in FRM, resulting in no flows installed
14:43:19 <colindixon> #info alagalah and tbachman say they are openeing bugs with openflow{java,plugin}
14:43:22 <alagalah> We see flows in CONF and we only see table0 correctly in OPER, and tables1-3 have drop flow
14:43:27 <colindixon> #link http://pastebin.com/Mkag1pRn
14:43:35 <alagalah> colindixon: I have OVSDB a heads up ...
14:43:43 <ttkacik> regXboi - yeah should be normalized on edges where value is parsed and constructed
14:43:43 <tbachman> another is that table 0 has all our flows, but tables 1, 2, and 3 only get the drop flow
14:43:52 <alagalah> colindixon: and also asked if they had a sandbox and cycles if they could sanity check with building with -U
14:43:59 <tbachman> there’s one other failure case/exception I’ve seen, but haven’t hit again
14:44:03 <alagalah> tbachman: Yep highlighed that...
14:44:07 <colindixon> abhijitkumbhare: do you know what’s going on?
14:44:13 <colindixon> or can you look into it?
14:44:16 <regXboi> ttkacik: (smile)
14:44:22 <ttkacik> regXBoi: but that should be done systemically - which requires proper design for that
14:44:45 <abhijitkumbhare> no - something must have got broken
14:45:08 <ttkacik> regXBoi: and I do not believe in Lithium timeframe any fix for this will not be "hack"
14:45:26 <colindixon> #action abhijitkumbhare to follow up with the bugs that gbp is finding in ofj/ofp
14:45:31 <colindixon> tbachman: you’re filing bugs?
14:45:39 <regXboi> ttkacik: I'd argue file bugs against everything that doesn't canonicalize values...
14:45:44 <tbachman> in both cases, flows are in config, but not oper (i.e. oper reflects state of vSwitches)
14:45:46 <tbachman> colindixon: ack
14:45:50 <colindixon> tbachman: and can you get abhijitkumbhare to figure it out?
14:46:04 * tbachman can only type so fast ;)
14:46:06 <alagalah> colindixon: Heads up I ping rovarga_ too, rovarga_ you following this ?
14:46:21 <alagalah> colindixon: Yes tbachman is focusing on the bugs, I'm raising awareness and seeing if others have issues
14:46:26 <rovarga_> alagalah: follow what? :)
14:46:41 <alagalah> colindixon: I'll coordinate with shague flaviof to see if they are seeing it to, and tie them to same bug
14:46:53 <alagalah> rovarga_: :)
14:47:22 <ttkacik> regXboi: actually fixing that in restconf would result in hack
14:47:24 <regXboi> colindixon: I have a cross product notification topic ...
14:47:25 <colindixon> alagalah and rovarga_ did you sync to cover what you need to?
14:47:35 <regXboi> ttkacik: no, I don't want to fix it in restconf
14:47:39 <colindixon> regXboi: you’re next?
14:47:44 <alagalah> colindixon: no, but I just pinged him so just ensuring I am closing the loop in case he was running things down on his end
14:47:45 <regXboi> that's what I *don't* want to do
14:47:46 <rovarga_> alagalah: first thing I got from oflibMichal was: do you have nicira extensions configured? :-)
14:47:47 <colindixon> regXboi: you’re next
14:47:50 <alagalah> colindixon: Cos I forgot about this meeting :D
14:47:51 <regXboi> colindixon: ack
14:48:03 <alagalah> rovarga_: oflibMichal Well... yeah
14:48:04 <ttkacik> regXboi: so you are talking mostly about internal apps which explicitly construct these types?
14:48:06 <rovarga_> alagalah: (re: your pastebin)
14:48:07 <tbachman> bug #1 https://bugs.opendaylight.org/show_bug.cgi?id=2895
14:48:11 <tbachman> abhijitkumbhare: ^^^
14:48:25 <alagalah> rovarga_: oflibMichal ^^^^^^
14:48:30 <regXboi> ttkacik: I'll explain after I'm done with this other topic
14:48:41 <colindixon> regXboi: go for it
14:48:46 <alagalah> colindixon: Ok, so should we take this of ofplugin for now and clear the floor for topics?
14:49:06 <alagalah> colindixon: we got awareness, thats all...  tbachman abhijitkumbhare oflibMichal See you on -ofplugin :)
14:49:10 <regXboi> #info the initial yang model for neutron in https://git.opendaylight.org/gerrit/#/c/15989/ has been merged
14:49:16 <abhijitkumbhare> yes - alagalah  sounds good
14:49:33 <regXboi> #info there are edits to it in queue as we adjust it to the openstack data models
14:49:42 <regXboi> but its there for folks to look at and get ready for
14:49:46 <colindixon> #link https://git.opendaylight.org/gerrit/#/c/15989/ link to the patch that will show up in the minutes
14:49:54 <regXboi> #info but it is there for folks to look at and get ready for
14:50:06 <regXboi> colindixon: that's it
14:50:14 <colindixon> thanks!
14:50:39 <colindixon> any other topics?
14:50:51 <regXboi> ttkacik: what I'm saying is that where instances of the particular type is constructed, it should be constructed in canonical form
14:51:28 <regXboi> ttkacik: if the instance is received in a message from an external source (e.g. from openstack for example), the receiving module should canonicalize the instance
14:51:45 <tbachman> bug #2: https://bugs.opendaylight.org/show_bug.cgi?id=2896
14:51:46 <colindixon> #info regXboi and ttkacik have more conversations on the DE:AD::BE:EF in the backgrond (see the full logs)
14:51:49 <tbachman> abhijitkumbhare: ^^^
14:52:08 <regXboi> ttkacik: I can say that I have tasks for NN to do that with incoming ipv6 and MAC addresses
14:52:11 <rovarga_> regXboi: silently?
14:52:24 <colindixon> #info as part of M3 (which all projects have passed) is to provide an outline for their documentation
14:52:43 <regXboi> rovarga_: yes... silently - that's the whole point of the "be conservative in what you send and liberal in what you accept" credo
14:52:47 <colindixon> #info as of last night only 12 of the 44 projects had actually submitted a patch to the docs repo
14:53:18 <colindixon> #link https://lists.opendaylight.org/pipermail/documentation/2015-March/000401.html for a full report with links to patches as of last night
14:53:19 <regXboi> colindixon: I saw your reviews - will see what can be done when resources have time
14:53:24 <rovarga_> regXboi: the reason I am asking is that historically, especially for restconf, people have been adamant about being able to interpret interactions as if they were plain strings
14:53:51 <regXboi> rovarga_: I fail to see how I'm saying something other than that
14:54:21 <rovarga_> regXboi: well.. for restconf that means that we end up putting a resource somewhere else, because if ipv4 address is in the key, normalization will force it to be a different thing
14:54:22 <colindixon> #info colindixon points out that means that more than 2/3 of projects are techincally not past their M3 deliverables
14:54:31 <rovarga_> regXboi: s/ipv4/ipv6/
14:54:37 <colindixon> #action ALL PROJECTS please make sure you’ve submitted your docs patches
14:54:51 <hideyuki> colindixon: What patches are expected?
14:54:52 <colindixon> #info colindixon has also made sure all project docs patches have been reviewed or merged as of last night
14:54:58 <Prem> Should a lightweight peer review be  planned for documentation?  Atleast this would ensure the documentation is effective for end users/customers
14:55:18 <colindixon> #link https://wiki.opendaylight.org/view/CrossProject:Documentation_Group:Lithium_Project_Documentation_Requirements#Step-by-step_Guide the step-by-step guide to complete documentation and submit a patch
14:55:22 <colindixon> hideyuki: ^^^^^^
14:55:27 <regXboi> rovarga_: understood, but  I would argue that using something other than canonical ipv6 format is just asking for trouble
14:55:32 <colindixon> Prem: we’re doing that
14:55:37 <colindixon> as part of reviewing the patch
14:55:51 <Prem> colindixon: ok. Thanks!
14:56:00 <colindixon> any more topics
14:56:01 <rovarga_> regXboi: I know, I agree with you, but this is drawing a line, so let's be clear about it
14:56:03 <hideyuki> colindixon: I'll check it. I didn't notice this.
14:56:12 <regXboi> rovarga_: yep - I'm drawing a line
14:56:18 <rovarga_> regXboi: I would go with postel-was-wrong and reject non-canonical queries
14:56:25 <regXboi> rovarga_: actually, I'm drawing several lines
14:56:36 * tbachman worries that regXboi will go postel ;)
14:56:46 * rovarga_ lol
14:57:04 <regXboi> rovarga_: my problem with rejecting non-canonical queries is that violates the principal of least surprise
14:57:14 * regXboi IS actually going postel
14:57:22 * regXboi but not postal
14:57:42 <colindixon> new topics
14:57:43 <colindixon> going once
14:57:51 <rovarga_> colindixon: ah... netty upgrade
14:57:51 <colindixon> anyone?
14:58:05 <colindixon> #info rovarga_ wants to talk aobut Netty upgrades
14:58:06 <regXboi> rovarga_: although, if RESTconf supports 3xx redirects, then the problem can be made moot
14:58:08 <colindixon> rovarga_: the floor is yours
14:58:12 <rovarga_> we got an upgrade of netty overnight (4.0.24->4.0.26)
14:58:22 <rovarga_> #info  we got an upgrade of netty overnight (4.0.24->4.0.26)
14:58:31 <rovarga_> #info requested by USC
14:58:44 <rovarga_> #info we have weird breakage in bgpcep as a consequence
14:59:07 <rovarga_> #info still diagnosing and trying to figure out WT?, but we may end up needing a revert
14:59:08 <regXboi> rovarga_: only bgpcep?
14:59:29 <rovarga_> regXboi: bgpcep I know of immediately, am quite busy, so cannot check others
14:59:40 <regXboi> rovarga_: thx
14:59:54 <rovarga_> regXboi: and I could replicate it locally, but can no longer do so
14:59:57 <colindixon> rovarga_: thanks
15:00:02 <regXboi> #info while rovarga_ knows of breakage in bgpcep first hand, other projects should check
15:00:12 <rovarga_> regXboi: so, this is just a heads up, we obviously would like to not go back
15:00:13 <regXboi> colindixon: that may need to be made an action
15:01:12 <rovarga_> #info it may be related to jenkins, but we are not sure yet
15:01:39 <colindixon> so the question is, does USC really need the upgrade?
15:01:51 <colindixon> do we have somebody from USC here?
15:02:12 <colindixon> it appears not
15:02:51 <colindixon> #action rovarga_ to try to fix whatever bug the netty upgrade causes, and if that’s too complictaed talk to USC about why they need the upgrade and think about reverting the upgrade
15:03:16 <colindixon> #info colindixon notes that it should not be somethign unliaterally decided (either by USC or by BGP PCEP)
15:03:30 <colindixon> other topics?
15:03:46 <regXboi> colindixon: that last note should probably get escalated up
15:03:58 <regXboi> because we've had this happen a couple of times now (I think)
15:04:20 <colindixon> #info you mean version management in generaal?
15:04:41 <tbachman> info?
15:04:48 <colindixon> #undo
15:04:48 <odl_meetbot> Removing item from minutes: <MeetBot.ircmeeting.items.Info object at 0x1a9c950>
15:05:19 <colindixon> #action colindixon to work with the TSC to consider recommending how to change versions in odlparent. maybe require a reviewer from every project that currently uses the dependency to avoid breakages.
15:05:22 <colindixon> other topics
15:05:23 <rovarga_> so third party deps are now implicitly under control of odlparent
15:05:49 <rovarga_> colindixon: from every project is denagerous -- note how many stalls we have right now
15:06:13 <colindixon> rovarga_: note “maybe” :-)
15:06:42 <colindixon> ok
15:06:44 <colindixon> other topics?
15:06:44 <rovarga_> colindixon: I know, but am still cautious
15:06:46 <rovarga_> :-)
15:07:19 <rovarga_> ah ...
15:07:30 <rovarga_> we are finalizing BUG-2399 (automatic containers)
15:07:47 <rovarga_> should be ready to land this week
15:08:08 <rovarga_> #info yangtools is finalizing BUG-2399 (automatic containers)
15:08:16 <colindixon> #link https://bugs.opendaylight.org/show_bug.cgi?id=2399 the bug
15:08:27 <colindixon> ok
15:08:29 <rovarga_> #info we will try csit and provide a heads-up before merging
15:08:35 <colindixon> more topics?
15:09:29 <colindixon> going once
15:10:27 <colindixon> going twice
15:10:32 <colindixon> #endmeeting