1. 23 Apr, 2015 7 commits
    • Change-Id: I0035c8cdd9f909af24a47b0db04d306c33aa8c44
      Sho SHIMIZU authored
    • Change-Id: Ie8fad0186f5a41596877463c0293748e6cf2d74f
      Jonathan Hart authored
    • Change-Id: Ia3fc4ab8406dadcecc5d718e905a951f77a807cf
      Ayaka Koshibe authored
    • Change-Id: Idd845ac2cb2ac2739735c384bd8f096fb975210c
      Thomas Vachuska authored
    • 1.merge private flow into regular flowrule subsystem.no mirror code any
      more.no change flowrule api.
      2.define a rich-data-type to carry private flow.
      3.modify OpenFlowRuleProvider.class to support for 3rd party private
      flow.i don't know whether is suitable.because this class name is
      relative with open flow protocal.
      4.fix some junit test bug caused by modification of FlowRule interface.
      
      Change-Id: I6c54d1e97f231a75bd1b416f0893e0379613d7ce
      jcc authored
    • …-l] [remote-ip [{karaf-instance-id|-} [ere-pattern]]]
      
      Change-Id: I598f0f5dd5f7f5436c0459f93944d0303cfa355e
      Thomas Vachuska authored
    • Addressed a few issues found while using the flow objectives across a cluster:
       * Flow objectives should be installable from any node, not just the master.
         Therefore we need to ensure all nodes initialize a driver for each switch.
       * We no longer store a list of objectives that are waiting for the switch
         to arrive. If the we don't know about the switch yet we'll try a few times
         over a few seconds to find it, but after that we'll give up and report an
         error to the client.
       * Default drivers need to be available when the FlowObjectiveManager starts
         up, otherwise it is common to get flow objective requests before any
         drivers have been loaded.
      
      Change-Id: I1c2ea6a223232402c31e8139729e4b6251ab8b0f
      Jonathan Hart authored
  2. 22 Apr, 2015 10 commits
  3. 21 Apr, 2015 16 commits
  4. 20 Apr, 2015 7 commits