Re: [controller-dev] OpenFlow Plugin & OpenFlow Java Bugs Blocking other projects

Thomas Bachman

I haven't tried the latest in a bit, but this bug:

was mostly fixed. I say mostly because the Nicira extensions that are needed by the regular GBP POC and by OVSDB were working (e.g. set tunnel ID, tunnel dest, use of registers, etc.). However, the extensions needed for the GBP/SFC integration still weren't when I tested this last. Specifically, the setting of the NSI/NSP fields in the NSH header weren't working, if I recall correctly.



On Mon, Apr 6, 2015 at 12:42 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
So the following was fixed by Ed on Friday (will remove it from the weather page):

Is the following still an issue?

    Are there any other blocker issues for OVSDB/GBP?

    Will follow up on the other bugs like the AD-SAL (Hideyuki) issue in a separate email.

    On Thu, Apr 2, 2015 at 9:39 AM, Abhijit Kumbhare <abhijitkoss@...> wrote:

    We are having a couple of blocking bugs affecting other projects:

    These are being worked on by Michal Rehak & he will be providing an update on these soon.


    On Thu, Apr 2, 2015 at 8:11 AM, Colin Dixon <colin@...> wrote:
    Two comments:

    1.) This should be discussed via a mailing list. If it is, it should be linked from here so others can follow it easily:

    2.) Please keep the weather page up to date. It sounds like maybe this should have been announced to weather, but at the very least, we should keep tracking it there so others can keep up to date. For instance, there's no information about what actually happened or how to tell if this is the same bug somebody else is seeing right now.


    On Thu, Apr 2, 2015 at 10:15 AM, Keith Burns <alagalah@...> wrote:


    I know some of us on the distro have discussed ideas on rollback, communication (see weathermap) etc.

    Trust me, I'm hurting too :)

    The offset thing is a enormous benefit here. I'm glad I'm seeing this now rather than deep into my API to code freeze cycle.

    Perhaps there is a middle ground.

    Abhijit, in lieu of reverting, which from the outside looking in seems like the cleanest option, is there another way? Often times we have had to back out, say OFP, patches and build w -nsu until we can test a patch. This is fine if we know the patch (and yes if we had better verify jobs for GBP in jenkins this would be easier) but often times pinpointing the patch to rollback is desperately difficult, espec when multiple projects are involved and moving models etc.

    Is it possible for the projects involved to give us a list of git checksums to rollback to so we can work from that without each project arbitrarily working this out for themselves?

    If this is too complicated, then I'd humbly suggest we are back to a revert conversation.

    On Apr 2, 2015 5:50 AM, "Flavio Fernandes" <ffernand@...> wrote:

    Thanks for the update Abhijit.

    My only hope is that you and your team understand that issues like this have a profound impact in odl projects that depend on a
    reliable openflowplugin implementation.

    While I completely understand the need to add new features, I wish there was a way I could control _when_ I start using them.
    Right now, I find development in master-snapshot a bit too fragile. I longer for the ability of having a timesatmp-like concept, so I
    could easily ‘try’ the latest and just as easily ‘go back to my cozy hole’ when the weather is adverse and my deliverables are pressing.


    — flavio

    On Apr 1, 2015, at 11:24 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

    Keith, Flavio & Phil,

    Unfortunately I missed the IRC meeting today - apologies - had planned to attend it side-by-side with another phone/video conf meeting (but totally missed it while debugging an issue with the video conf equipment). Prem forwarded me the meeting notes [1] as well as the log [2]. The issues raised as blockers in the IRC meeting were bugs 2895, 2896 & 2913. Last week a big change called the model update was pushed in (OpenFlow plugin & Java) - which caused bugs 2895 & 2896 (which we discussed during last week's IRC meeting). After the meeting it was discovered the model update changes were responsible for the breakage - which is when I had sent the email suggesting backing out the changes (referenced by Keith/others in the meeting today). 
    However the 2 Michals & Martin thought they could fix it & did a lot of work to fix it (with Thomas Bachman's help) - and Michal finally pushed the patch on a 7th or 8th try over the weekend to fix the deserialization issues (and thought it also fixed 2895). Unfortunately it seems to have not fixed 2895 and uncovered a new bug 2913 (GroupMods not being written to second switch). 

    Michal R & Michal P - The options now would be to either back out the model update changes, fix the serialization/deserialization issues & then put back the model update changes OR fix the issues directly. Please decide which will be the best option in terms of least disruption to other projects (with perhaps a hit to OpenFlow schedules).


    On Sun, Mar 29, 2015 at 11:12 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:
    Just wanted to let you guys know that the following seems to be a blocker for GBP:

    I believe Michal Rehak had already taken a look with Keith today. 

    controller-dev mailing list

    Join to automatically receive all group messages.