1. 16 Nov, 2018 1 commit
  2. 13 Sep, 2018 1 commit
    • Matthew Sykes's avatar
      [FAB-10804] queue chaincode tx on container start · 8a7737d1
      Matthew Sykes authored
      
      
      Until now, when transactions arrive for a chaincode that is not running,
      the first transaction causes the chaincode to launch while all others
      are rejected until the chaincode launch has completed. This is
      unfriendly and unexpected behavior.
      
      With this change, when transactions arrive for chaincode that is
      launching, the transactions will be queued until the launch process has
      completed.
      
      If the launch fails for some reason, all queued transactions will be
      terminated with the error from the launch. If the initial launch times
      out, all queued transactions (regardless of arrival) will be terminated
      with the timeout error.
      
      Change-Id: I12a9750b1a57e3e494cf4026539ea490dcf0573e
      Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      8a7737d1
  3. 12 Sep, 2018 1 commit
  4. 07 Sep, 2018 1 commit
    • senthil's avatar
      FAB-11455 peer side changes to support pagination · 0ee45ac4
      senthil authored
      
      
      We need to make necessary changes in the core/chaincode/handler.go for
      pagination of results. Currently, the handler.go in the peer calls the ledger
      to execute queries (range query, rich query) on behalf of the chaincode.
      On an execution of a query, the ledger returns an iterator. Using the
      iterator, peer constructs the query response with records and send the
      response to chaincode.
      
      This CR makes the following changes to support pagination of results.
      
      When a pagination of results is enabled for a query (i.e., when the query
      metadata is passed with either pageSize or a bookmark or both for range/rich
      queries), the peer would call the new pagination enabled range/rich query
      APIs at ledger which would return a response metadata in addition to an
      iterator. The response metadata would contain the next bookmark and the
      number of records fetched for the query. Peer retrieves all fetched records
      from ledger, constructs a query response including both records and
      response metadata. The chaincode can pass on the bookmark in the response
      metadata to the application/sdk.
      
      Change-Id: Id770dd184369d1f7eaa30f046e1923c8fde564a5
      Signed-off-by: default avatarsenthil <cendhu@gmail.com>
      Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
      0ee45ac4
  5. 05 Sep, 2018 1 commit
  6. 16 Jul, 2018 16 commits
    • Jason Yellick's avatar
      FAB-11037 Remove InvocationSpec from chaincode pkg · 1fe243f8
      Jason Yellick authored
      
      
      This CR finally completes removing the legacy data "ChaincodeSpec"
      structures from the non-shim related pieces of the chaincode package.
      To maintain compatibility with the existing chaincode images, the
      ChaincodeSpec still exists in the handler path, and to maintain
      compatibility with the legacy lifecycle, a single deployment spec
      acceing execute method is available.  Both of these should be removed in
      time.
      
      Change-Id: I5659695a55e0947a1ccec23721192a4c88177b38
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      1fe243f8
    • Jason Yellick's avatar
      FAB-11036 Remove the transaction parms from cccid · 354c9242
      Jason Yellick authored
      
      
      The chaincode context structure help the channel id, the chaincode name,
      chaincode version, and other things unrelated to identifying a chaincode
      like the proposal bytes.  These other fields are also stored in the
      transaction parms, so, they are not needed and are confusing when in the
      chaincode context.  This CR removes them.
      
      Change-Id: I892bd24cc621800cd1b089d90d0a603e112ae84c
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      354c9242
    • Jason Yellick's avatar
      FAB-11034 Replace context with explicit params · 4645c3ac
      Jason Yellick authored
      
      
      Presently, there is a "context" which is passed into the chaincode
      package.  Rather than actually be used for its intended purpose (of
      waiting for cancelation), the context is never actually checked.
      Instead, it simply carries the transaction simulators around in an
      opaque fashion.
      
      It's much better to make these transaction simulators to be passed in
      explicitly.  Additionally, some other facets like TxID and the assorted
      proposals really fit much more naturally with the simulators and not
      with the chaincode context.  So, this CR brings them in as well.
      
      Change-Id: I7e0c43af22f1e96b8d302e5cf877e7beec36598b
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      4645c3ac
    • Jason Yellick's avatar
      FAB-11033 Complete removing spec from Launch · b7157a4d
      Jason Yellick authored
      
      
      This CR completes removing the chaincode spec from all of the launch
      related functions.
      
      Change-Id: I10ac1b205f45794dc45dadf4140ec07c7f1e9ca1
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      b7157a4d
    • Jason Yellick's avatar
      FAB-11031 Remove 'Syscc' from CCContext · d72773ea
      Jason Yellick authored
      
      
      The syscc attribute is only used as part of deciding whether or not to
      print a log message.  And, it is unnecessary in this case, so, removing
      it.
      
      Change-Id: I17ff4f654984240deddb726cc5902f83232993c3
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      d72773ea
    • Jason Yellick's avatar
      FAB-11029 Make stop take container info · 4f10a144
      Jason Yellick authored
      
      
      Yet another step to remove the chaincode deployment spec dependencies
      from the chaincode package.
      
      Change-Id: I4db64faff97da097e6ab6713394c1ba18539faf3
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      4f10a144
    • Jason Yellick's avatar
      FAB-11026 Remove lifecycle shim and use LSCC inst · 620dffee
      Jason Yellick authored
      
      
      There was a shim created by the chaincode package to abstract away
      lifecycle operations.  Over time, this shim has done less and less as
      the LSCC implementation has exposed more function directly rather than
      as chaincode calls.  Now, the shim is only translating names.  This CR
      simply aligns the names and removes the shim.
      
      Change-Id: Ide10dbe5b872752458dca87b0a520b946a644afd
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      620dffee
    • Jason Yellick's avatar
      FAB-10995 runtime_launcher chaincode spec removal · 03aabd78
      Jason Yellick authored
      
      
      This CR completes the removal of the chaincode spec from the
      runtime_launcher.go file.  There is some additional refactoring,
      especially of the test required, but this will follow in a subsequent
      CR.
      
      Change-Id: I8b71811f534fee6fcda77bc7bafb64c319a10ab3
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      03aabd78
    • Jason Yellick's avatar
      FAB-10994 Remove chaincode spec from Launch · 2fffd02e
      Jason Yellick authored
      
      
      Minor change to bring the chaincode spec one step closer to death in the
      runtime_launcher.go file
      
      Change-Id: Ib87bd4095883785de1895bdba475ed0e2cb6ae97
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      2fffd02e
    • Jason Yellick's avatar
      FAB-11024 ChaincodeContainerInfo to ccprovider · f5182d4c
      Jason Yellick authored
      
      
      Prior to changing the ChaincodeProvider interface to use
      ChaincodeContainerInfo instead of DeploymentSpecs, the
      ChaincodeContainerInfo must be removed from the chaincode/lifecycle
      package to avoid import cycles.
      
      Change-Id: I9928726d4fcb04dc31841ba392fd20130448d8ae
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      f5182d4c
    • Jason Yellick's avatar
      FAB-10996 Cleanup runtime launcher interface · 0e578a8c
      Jason Yellick authored
      
      
      Presently, the runtime launcher has a dependency on lifecycle that
      doesn't actually need to exist.  Instead, the runtime launcher should
      simply accept a description of the chaincode to launch.
      
      Change-Id: Ie9703afa8d7567e188f3e0b4cf59301ef29d6890
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      0e578a8c
    • Jason Yellick's avatar
      FAB-11023 Unhide system chaincode provider · 5f9de089
      Jason Yellick authored
      
      
      There is a single hidden field in the chaincode_support.go
      ChaincodeSupport struct.  This is the system chaincode provider.
      Although there is no obvious need for un-hiding this field, it is
      inconsistent and distracting when looking at the code.
      
      Change-Id: I23fd44a32479c434ad04ff93c003656a3a5c83fd
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      5f9de089
    • Jason Yellick's avatar
      FAB-11000 Remove unnecessary context · 3eebcf31
      Jason Yellick authored
      
      
      There is a context passed into all of the Start/Stop methods for the
      chaincode container management.  Historically, the only ever reference
      to it was via a value on the context to get back the chaincode support.
      However, since this dependency has been remeoved, it no longer serves
      any point, other than to complicate method signatures and cause general
      confusion.
      
      It's clear whenever it was wired, the intent was to eventually make the
      dockerclient etc. have cancelable contexts.  However, this work was
      never done, and it is sufficiently low priority as to not even appear in
      the backlog.  It is trivial enough to add back the context dependency if
      it's ever shown that it's useful.
      
      Change-Id: I8bcf0922594a5e40cb187687849b49ad5653ae89
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      3eebcf31
    • Jason Yellick's avatar
      FAB-10998 GetChaincodeData to use LSCC directly · d861bbfe
      Jason Yellick authored
      
      
      Now that LSCC can be queried directly for chaincode definitions instead
      of having to go the roundabout way of invoking chaincode, the assorted
      internal users of 'getccdata' can be converted to use the new interface.
      
      Change-Id: Ic435742817643d2dc08d83afe2f66980c649b56a
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      d861bbfe
    • Jason Yellick's avatar
      FAB-10992 Lifecycle abstraction to return ccci · 1160b118
      Jason Yellick authored
      
      
      As this whole series is about removing the chaincode deployment from the
      chaincode package, it must also be removed from the interfaces of the
      packages it depends on.  This CR simply makes the lifecycle interface
      return a lifecycle.ChaincodeContainerInfo instead of the CDS.
      
      Change-Id: I50f400aa09867021e1c22581279dfc889944df22
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      1160b118
    • Jason Yellick's avatar
      FAB-10987 GetChaincodeDeploymentSpec direct call · f4ed7424
      Jason Yellick authored
      
      
      Presently, the chaincode/lifecycle/lifecycle.go
      GetChaincodeDeploymentSpec makes a chaincode invocation of LSCC to
      retrieve information which is directly and trivially available.  This CR
      passes in a reference to LSCC so that all of the chaincode overhead and
      complexity can be eliminated.
      
      Change-Id: I57523144264e3efffc8cb81ff5d72f0138d1a79c
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      f4ed7424
  7. 10 Jul, 2018 4 commits
    • Jason Yellick's avatar
      FAB-10978 Remove spec from container_runtime · e3d70517
      Jason Yellick authored
      
      
      The container runtime currently takes both a cccid and a deployment
      spec.  And pulls some information from each.  Instead, it should take a
      structure which contains exactly the information it needs.
      
      Change-Id: I6c421a0f943aecef481be0b8b6ad6b3a7f5c4b0c
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      e3d70517
    • Jason Yellick's avatar
      FAB-10977 Extract lifecycle to interface · b1dd84b9
      Jason Yellick authored
      
      
      This is step two to remove lifecycle from the chaincode package,
      replacing the explicit dependency in the tests on the lifecycle
      implementation with a mocked implementation.
      
      Change-Id: I4243d691d2de7dabac3af998c3b8b8354e80a602
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      b1dd84b9
    • Jason Yellick's avatar
      FAB-10976 Move lifecycle to its own package · 305c5ad9
      Jason Yellick authored
      
      
      Because of some errors with cyclical imports for the chaincode package
      tests which are not written as _test packages, we need to define a
      structure to represent a chaincode which is not the
      ChaincodeDeploymentSpec but which is also not inside of the chaincode
      package.  Defining this in the lifecycle portion makes sense, so as a
      prerequisite, moving lifecycle from the chaincode package, to a
      subpackage called lifecycle.
      
      Note: This introduces some stuttering, that will be remedied in a later
      CR.
      
      Change-Id: I8883b9fc39d7b23d42ba6df31389e5a9df248457
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      305c5ad9
    • Jason Yellick's avatar
      FAB-10975 Split Execute into Execute/ExecuteInit · 59182528
      Jason Yellick authored
      
      
      Presently, the Execute function can either take a
      'ChaincodeInvocationSpec' or a 'ChaincodeDeploymentSpec', and the path
      switches in a few different places depending on which it is.  This makes
      the code complicated and difficult to understand, and in the interest of
      removing the chaincode deployment spec entirely, this code path should
      be isolated.
      
      Change-Id: I1f54684dba5877b5c629a59d344803f6423cc3da
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      59182528
  8. 03 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-10825 Make platform latent dependency explicit · 9112ebfb
      Jason Yellick authored
      
      
      Many of the assorted 'utils' functions actually reach into the
      core/chaincode/platforms package to determine whether packages are
      valid.  This historically has all been done in a source-coupled way,
      pulling peer details into places it does not belong.  Although these
      'util' functions should be refactored and removed, for the time being,
      we can at least make the dependency on the platforms package explicit,
      but requiring that an instance be passed into these util functions.
      
      This has quite the ripple throughout the code, but the CR itself should
      be trivial to review.
      
      Change-Id: I0cc36e2f307474ddba7f6d20028a46f3aa94faf5
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      9112ebfb
  9. 22 May, 2018 2 commits
  10. 14 May, 2018 1 commit
  11. 10 May, 2018 7 commits
  12. 08 May, 2018 1 commit
    • Jason Yellick's avatar
      FAB-9729 Make VMCProcess non-package scoped · 143d35a5
      Jason Yellick authored
      
      
      The chaincode package has already been reworked to reference the
      VMCProcess function as an interface method.  This CR simply modifies the
      container package to make the VMCProcess function a method of
      VMController and exposes a constructor for creating the VMController.
      
      Change-Id: Ib08e77ece59b30d2564db065197782513c18d6d6
      Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      143d35a5
  13. 02 May, 2018 3 commits