Date   

Re: [Hyperledger TSC] CI/CD questions/discussion

Jonathan Levi (HACERA) <jonathan@...>
 

Also, the CI/CD still allows "people" and "processes" to break the build.

Speaking of the devil, we have just merged a fix (like an hour ago) that Jason pushed after hours...


I know some people got used to it, but really, this is not "normal".

Now, all of the pending CRs will (need to) be Rebase manually... and as some of you know, we have some issues with the "Rebase" button, with the parent issue... 

But even with that aside, it is a mess having 20+ builds running/pending due to the dilluge of rebases (and re-running builds).

While we should not change "everything" this week, there are many ongoing issues with the CI.

We have been discussing this serveral times (years), since the days of us voting for branches and development work flow, but if we are getting rid of Jenkins, let's also make sure that we get the basics right, because it is expensive, time/resources/dependencies-wise.

Thanks again,
Jonathan Levi

HACERA - To Blockchain with Confidence

Unbounded - To Network with Network



On Fri, Nov 30, 2018, 1:22 AM Jonathan Levi (HACERA) <jonathan@... wrote:
Dave (Mike and Hart), I am so glad this is being brought up again!

While I have a lot to say about this, I would like to point out that even though the Fabric devs historically we're/are the heavier/heaviest users of the Jenkins build... please let's not interpret this as if the Fabric devs and maintainers are happy with the current setup.

I can speak for myself though, to make things simpler. So, regarding #3, quickly:

"3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?"

We need to make the Jenkins (or CI) build setup a better solution <full stop>.

The current setup cost us more than an extra month with Fabric 1.3... and this is only for the Identity Mixer work that HACERA helped to productionize in Fabric 1.3. Zurich Research spent a LOT of time, due to receiving the wrong output / build errors from the CI... and not everybody was able to realize the chain of things that were wrong in the setup(s).

In all fairness, we have setup our own CI(s) as we couldn't rely anymore on some the results... 
so please, I don't want anybody to be "jealous" that most of the contributions to the CI scripts came from us, historically (some of them are there pre Fabric 0.5). I have spent quite a while talking about this with Gari (Singh) just today, as he is/was working to remove some of the old configuration that we needed back in the day with Greg's Makefile.

Still, these won't save the day... as we have a LOT on our plates. We really need some better infrastructure. Due we some capacity to deal with this?

Let alone failing, the CA turned out to not even build the latest, the integration was running against old images, and boy, some of these things spit out and deploy outputs all over the place (even in daily builds).

All the CI code is checked in to a repo, but honestly, it is really hard to track due to all these shell scripts and genius pre- and post- processing logic that is magically applied in so many cases... and some of us, mere mortals, cannot follow anymore.

We about to cut a release candidate in a few days, and I was/am actually about to report tomorrow not only that many builds fail... but also that some "successful" runs are definitely not supposed to be passing.

It is not optimal. We definitely need better tooling, given the number of contributes.

Please take a look at my last few merges... or at how many times I am submitting a "reverify" and "remerge" just to stabilize some of these insane error messages.

It is very easy to see what the CI is doing, but it is even more easy to see how much we struggling with tests that we need to re-run, in many times locally and then we synchronize through chat messages, to ascertain some consistency.

While I am less active this year on the TSC... this really needs attention, so Dave (Hart and Mike), and the TSC, thank you, thank you, thank you, in advance.

People "spat blood" towards the end of Fabric 1.3, to the level of us scheduling another full release (1.4) just for house-cleaning. We really need to re-think/re-visit that pattern of "being too busy to sharpen the saw".

------

I know, I know, it's close to Xmas time and not everybody likes to hear the truth about Santa (apparently this is a major realization in one's life. My biggest issue was the tooth fairy one, having broken a tooth by falling off  a skateboard straight on my face only to realize that I may get a similar tooth, at best, and forever be weary of strong Green apples. But hey! Let's not digress here! :D). If we want to discuss the CI problem, please let's keep the above in mind. Ramesh and others are working to capacity with every release, and we could/should give them a helping hand.

Sorry if this may extend the scope of work "slightly", but you guys are touching a really important topic. It needs much more work than "making it work not just for Fabric"... I would go as far as "making it work".

Will be happy to help too... so more questions or feedback is (always) welcome.


Thanks again,
Jonathan Levi

HACERA - To Blockchain with Confidence

Unbounded - To Network with Network




On Fri, Nov 30, 2018, 12:26 AM David Huseby <dhuseby@... wrote:
Hi TSC,

This morning Hart, Mike, and I met to discuss the plan for the Ursa
library CI/CD pipeline.  What actually happened was we took a good
look at the HL Jenkins setup and asked around about what all of the
other projects are using.  We came up with a list of questions we
decided to ask the TSC list about:

1) It appears that the HL Jenkins is only being used by Fabric, but a
lot of the build tasks are failing and have been for months.  Where
are Fabric's main CI builds happening?  Where are Fabric's CD binaries
being stored?

2) Can we wipe out all of the CI builds on HL Jenkins that have been
failing for months?

3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?

4) The HL Indy experience with GitLab suggests that GitLab may be a
better all around solution for CI for the HL projects.  The free,
self-hosted version of GitLab supports the features we need: LDAP
integration and CI/CD pipeline with API.  Can we try using that?
Jenkins is super clunky.

5) What is the official HL solution for build artifacts?  Where should
our CD upload the binaries?

That's it for now.  It turns out that each project has their own CI/CD
pipeline and only Fabric is using the HL one.  Indy is using Jenkins
run by Evernym and Sovrin but they are moving to GitLab soon.  Iroha
is using Jenkins run by Soramitsu.  Burrow uses Helm charts for
executing things and I'm still waiting on details about Sawtooth.

Ultimately I would like us to set up a CI/CD system that all of the
teams want to use.  I think the initial set of requirements are:

1) Well documented and easy to get going for a new project.
2) Easy to maintain.
3) Integrates with a well defined CD storage system.
4) Integrates with both Gerrit and GitHub.

Both Jenkins and GitLab meet #3 and #4.  But I think only GitLab meets
#1 and #2.  I'd like to set an instance up and evaluate it.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...




interoperability

Christopher Ferris
 

Recently, the subject of interoperability between vendor offerings of Hyperledger Fabric has become a hot topic of conversation. Specifically, being able to have a peer hosted by vendor offering A, join a pre-existing channel hosted by an orderer service in vendor offering B.

As you likely know, Hyperledger Fabric does indeed support this sort of configuration. However, we don't really have an easily automated approach to facilitating this.

Now, there are definitely business and consortia governance aspects to this that are far more involved, but that aside, I have spoken to a number of people interested in not only demonstrating that we can do this, but in helping develop the tools and metadata exchange format to allow this to be a much simpler, and automated solution -- rather than the rather cumbersome manual process we have today.

I see this as something that might happen in stages. The first stage is to have a number of independent offerings all interconnected in a demonstration similar to the Hyperledger Fabric Connect-a-thon we held almost a year ago. e.g. Let's get Oracle, SAP, Microsoft, Amazon and other providers all interconnected and demonstrating the Marbles application as we did last year. I think that there's interest in having this demonstrated at the Hyperledger Global Forum, but a short runway.

Stage two would be collaborating on an exchange format and a tool that could be used to facilitate the automation of what is presently a cumbersome manual process.

Stage three would be to incorporate this into a Fabric release and have it also integrated into a registry such as Unbounded.network.

The runway is short, but I think we can do this. Who's interested in pursuing this with me? 

Cheers

Chris


Re: User chaincode ACL to control access to user defined chaincode functions #fabric

Thanakrit Lee <thanakrit.lee.2014@...>
 

I see, I'm currently using the 1.2 version of Fabric as well, so I'm also not sure if there's any changes in ACL with 1.3. Thanks for the insight Srinivasan.


Re: User chaincode ACL to control access to user defined chaincode functions #fabric

Srinivasan Muralidharan
 

Hi Thanakrit Lee,
To add to Baohua's response, both approaches are "ACLs". The "resource based ACL" uses fabric's identity infrastructure directly (via MSP and policies) as opposed to the more traditional approach provided by "cid" library.

One thing to note, the resource ACL system is not confined to the predefined resource list and policies in sampleconfig. We can add our own resource strings and use them in any pluggable code (such as system chaincode plugin). So in that sense these should be extensible (you should be able to write a custom "ACL" system chaincode pluginwhich other user chaincodes can access to do access control.
NOTE- emphasize on "should" in the previous sentences ... I did get this to work a while back but not recently.

Murali


On Fri, Nov 30, 2018 at 3:01 AM Thanakrit Lee <thanakrit.lee.2014@...> wrote:

Awesome. Thanks Baohua.



--
Thanks,
Murali
"Practice is a means of inviting the perfection desired." - Martha Graham
“We ran and ran. We were exhausted, but we kept running.” - Homare Sawa after winning 2011 Women's Soccer world cup


Re: New Project Proposal: Fabric Desktop

Yi DENG
 

Hi Ale, 

Thanks for inviting. A playback is a good idea, and I would like to do it. But it seems to involve many arrangement issues, such as JIRA-issue, scrum meeting proposal, playback schedule. Could you help me out?


-----
Yi

On Thu, Nov 29, 2018 at 6:17 PM Alessandro Sorniotti <ale.linux@...> wrote:
Personally I'd like to learn more about this project: have you considered a playback (https://wiki.hyperledger.org/projects/fabric/playbacks) to let the community know more about it and start a discussion?

Thanks!
Ale

On Thu, 29 Nov 2018, at 10:29 AM, Yi DENG wrote:
> Dear Fabric Maintainers and All, 
>
> It is Yi. Recently, we developed a desktop app for Fabric. It is
> general-purpose, in other words, an API tool with GUI. We would like to
> contribute it to Hyperledger. 
>
> Right now, TSC is discussing and would like to know how Fabric
> maintainers think about this. Things like its relationship with Fabric;
> if it should be a top-level project or sub-project of Fabric; and how to
> maintain projects like this. It is pleased to hear from you. 
>
> TSC Dicsussion Details:
> https://lists.hyperledger.org/g/tsc/topic/new_project_proposal_fabric/28046677?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28046677
>  
>
> Proposal:
>
> https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit
> ( https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit )
>
>  
>
> Code repository:
>
> https://github.com/blockchain-desktop/hyperledger-fabric-desktop
>
> ----
>
> Yi DENG
>
>  
>
> Senior Software Engineer - Yonyou
>
>
>





--
_________________________
邓羿
Yi DENG


Re: User chaincode ACL to control access to user defined chaincode functions #fabric

Thanakrit Lee <thanakrit.lee.2014@...>
 

Awesome. Thanks Baohua.


Re: User chaincode ACL to control access to user defined chaincode functions #fabric

Baohua Yang
 

These are two things of different levels.
The ACL is to control how to access the API exposed by peer.
While Cid helps implement chaincode internal access control (if you look for chaincode function control).

On Fri, Nov 30, 2018 at 1:47 PM Thanakrit Lee <thanakrit.lee.2014@...> wrote:

Hello,

I've come to understand that the Access Control Lists (ACL) for Hyperledger Fabric is use for access control to chaincode resources. These resources (shown in sampleconfig) includes:

  • Lifecycle System Chaincode (lscc)
  • Query System Chaincode (qscc)
  • Configuration System Chaincode (cscc)
  • Miscellanesous peer function
  • Events resource

What I want to know is if the ACL can go deeper into the user chaincode, controlling the access to the user chaincode functions resource?

I've also had a look at CID library which I've used in a chaincode before, to control the access to functions based on the client identity (invoker attributes). I found that using this library extends the length of my chaincode, and therefore I'm looking for another way to implement access control possibly using the above ACL method, if it allows to do so.

Kind regards, Thanakrit Lee.



--
Best wishes!

Baohua Yang


User chaincode ACL to control access to user defined chaincode functions #fabric

Thanakrit Lee <thanakrit.lee.2014@...>
 

Hello,

I've come to understand that the Access Control Lists (ACL) for Hyperledger Fabric is use for access control to chaincode resources. These resources (shown in sampleconfig) includes:

  • Lifecycle System Chaincode (lscc)
  • Query System Chaincode (qscc)
  • Configuration System Chaincode (cscc)
  • Miscellanesous peer function
  • Events resource

What I want to know is if the ACL can go deeper into the user chaincode, controlling the access to the user chaincode functions resource?

I've also had a look at CID library which I've used in a chaincode before, to control the access to functions based on the client identity (invoker attributes). I found that using this library extends the length of my chaincode, and therefore I'm looking for another way to implement access control possibly using the above ACL method, if it allows to do so.

Kind regards, Thanakrit Lee.


Re: [Hyperledger TSC] CI/CD questions/discussion

Jonathan Levi (HACERA) <jonathan@...>
 

Dave (Mike and Hart), I am so glad this is being brought up again!

While I have a lot to say about this, I would like to point out that even though the Fabric devs historically we're/are the heavier/heaviest users of the Jenkins build... please let's not interpret this as if the Fabric devs and maintainers are happy with the current setup.

I can speak for myself though, to make things simpler. So, regarding #3, quickly:

"3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?"

We need to make the Jenkins (or CI) build setup a better solution <full stop>.

The current setup cost us more than an extra month with Fabric 1.3... and this is only for the Identity Mixer work that HACERA helped to productionize in Fabric 1.3. Zurich Research spent a LOT of time, due to receiving the wrong output / build errors from the CI... and not everybody was able to realize the chain of things that were wrong in the setup(s).

In all fairness, we have setup our own CI(s) as we couldn't rely anymore on some the results... 
so please, I don't want anybody to be "jealous" that most of the contributions to the CI scripts came from us, historically (some of them are there pre Fabric 0.5). I have spent quite a while talking about this with Gari (Singh) just today, as he is/was working to remove some of the old configuration that we needed back in the day with Greg's Makefile.

Still, these won't save the day... as we have a LOT on our plates. We really need some better infrastructure. Due we some capacity to deal with this?

Let alone failing, the CA turned out to not even build the latest, the integration was running against old images, and boy, some of these things spit out and deploy outputs all over the place (even in daily builds).

All the CI code is checked in to a repo, but honestly, it is really hard to track due to all these shell scripts and genius pre- and post- processing logic that is magically applied in so many cases... and some of us, mere mortals, cannot follow anymore.

We about to cut a release candidate in a few days, and I was/am actually about to report tomorrow not only that many builds fail... but also that some "successful" runs are definitely not supposed to be passing.

It is not optimal. We definitely need better tooling, given the number of contributes.

Please take a look at my last few merges... or at how many times I am submitting a "reverify" and "remerge" just to stabilize some of these insane error messages.

It is very easy to see what the CI is doing, but it is even more easy to see how much we struggling with tests that we need to re-run, in many times locally and then we synchronize through chat messages, to ascertain some consistency.

While I am less active this year on the TSC... this really needs attention, so Dave (Hart and Mike), and the TSC, thank you, thank you, thank you, in advance.

People "spat blood" towards the end of Fabric 1.3, to the level of us scheduling another full release (1.4) just for house-cleaning. We really need to re-think/re-visit that pattern of "being too busy to sharpen the saw".

------

I know, I know, it's close to Xmas time and not everybody likes to hear the truth about Santa (apparently this is a major realization in one's life. My biggest issue was the tooth fairy one, having broken a tooth by falling off  a skateboard straight on my face only to realize that I may get a similar tooth, at best, and forever be weary of strong Green apples. But hey! Let's not digress here! :D). If we want to discuss the CI problem, please let's keep the above in mind. Ramesh and others are working to capacity with every release, and we could/should give them a helping hand.

Sorry if this may extend the scope of work "slightly", but you guys are touching a really important topic. It needs much more work than "making it work not just for Fabric"... I would go as far as "making it work".

Will be happy to help too... so more questions or feedback is (always) welcome.


Thanks again,
Jonathan Levi

HACERA - To Blockchain with Confidence

Unbounded - To Network with Network




On Fri, Nov 30, 2018, 12:26 AM David Huseby <dhuseby@... wrote:
Hi TSC,

This morning Hart, Mike, and I met to discuss the plan for the Ursa
library CI/CD pipeline.  What actually happened was we took a good
look at the HL Jenkins setup and asked around about what all of the
other projects are using.  We came up with a list of questions we
decided to ask the TSC list about:

1) It appears that the HL Jenkins is only being used by Fabric, but a
lot of the build tasks are failing and have been for months.  Where
are Fabric's main CI builds happening?  Where are Fabric's CD binaries
being stored?

2) Can we wipe out all of the CI builds on HL Jenkins that have been
failing for months?

3) Can we make significant changes to Jenkins to make it less Fabric
specific and a better solution for all of the other projects?

4) The HL Indy experience with GitLab suggests that GitLab may be a
better all around solution for CI for the HL projects.  The free,
self-hosted version of GitLab supports the features we need: LDAP
integration and CI/CD pipeline with API.  Can we try using that?
Jenkins is super clunky.

5) What is the official HL solution for build artifacts?  Where should
our CD upload the binaries?

That's it for now.  It turns out that each project has their own CI/CD
pipeline and only Fabric is using the HL one.  Indy is using Jenkins
run by Evernym and Sovrin but they are moving to GitLab soon.  Iroha
is using Jenkins run by Soramitsu.  Burrow uses Helm charts for
executing things and I'm still waiting on details about Sawtooth.

Ultimately I would like us to set up a CI/CD system that all of the
teams want to use.  I think the initial set of requirements are:

1) Well documented and easy to get going for a new project.
2) Easy to maintain.
3) Integrates with a well defined CD storage system.
4) Integrates with both Gerrit and GitHub.

Both Jenkins and GitLab meet #3 and #4.  But I think only GitLab meets
#1 and #2.  I'd like to set an instance up and evaluate it.

Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...




Documentation Workgroup: Agenda for Friday, 30 Nov

Anthony O'Dowd <a_o-dowd@...>
 

Hi All,

Returning from Thanksgiving, we will hold the documentation workgroup  on Friday, 30 Nov.  Joe will be our host this week! We run the meeting twice during the day to make it easier for both Eastern and Western hemispheres.  See meeting times at the bottom of this note.  Sign-in details below.

We'll kick-off this week's meeting with a 1.4 status update from Pam and Joe. Version 1.4 code and docs are closing out, so we'll have a close-to-final view on the release. We'll then review the Developing Applications topic, which is close to completion -- in the process of final review and merging. We'll also consider our remaining subtopics: smart contract contexts and APIs. Chris and Isaac will give an update on chaincode and transactions, and we'll quickly checkpoint the policy topic.

If you'd like to contribute to these or another topic, please join the call -- there are now lots of people who are keen to help you understand this material by creating a topic.

The full agenda is available for you to read here : https://drive.google.com/open?id=16E8ChyL9MjPWcBycjnr2ICLjOd3PWEwr
Feel free to post comments to the mailing list, so that we can include at the meeting. Or you can just come along, listen and discuss - you're always welcome!

Very best regards, Anthony.

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

Zoom should work in the browser.  I will open the call 5 minutes early so that folks can test it out. I'll also monitor the RocketChat at https://chat.hyperledger.org/channel/fabric-release so that if anyone has issues, ping me there!

More Zoom connection options at the bottom of this note.

The meeting times are as follows:

Meeting 63A: Friday 30 Nov  
                   1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time
   
Meeting 63B: Friday 23 Nov
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1200 Brasil Standard Time
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time
 
More Zoom details
----------------

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/6223336701

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Re: [Hyperledger Quilt] Regarding escrow and handling payments

vipinsun@...
 

Hello Arvind,
Better ask the stripe question on one of the HL fabric channels or mailing lists. I hear that  they have Stellar  integration which might help.
Vipin


On Nov 29, 2018, at 9:19 AM, Arvind Subramanian <arvind.subramanian.286@...> wrote:

Hi All, 

Apologies if this is not the right channel to direct my query. If  so, please let me know about the appropriate mailing list / forum. 
 
I am trying to figure out if I could use Quilt for escrow functionality for an application  with Fabric. 

While I do see a reference that is possible in the wiki -


I was unable to get a reference to working demo/ P.O.C .  

These are my questions: 

1) If someone could give a reference to a publicly available demo/code-base with Quilt as Escrow, I would greatly appreciate it. 

2)Would it be possible for anyone to shed light on the best approach to handle Stripe integration with Hyperledger Fabric?  

Regards,
Arvind  


Unable to run typescript version of balance-transfer app TSError: ⨯ Unable to compile TypeScript

Siddharth Jain
 

Hi All,

I am trying to run the typescript version of balance-transfer app using the instructions provided here but get this error:
============== node modules installed already =============
cp: cannot create regular file 'node_modules/fabric-client/index.d.ts': No such file or directory
cp: cannot create regular file 'node_modules/fabric-ca-client/index.d.ts': No such file or directory


/home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:307
        throw new TSError(formatDiagnostics(diagnosticList, cwd, ts, lineOffset))
              ^
TSError: ⨯ Unable to compile TypeScript
app.ts (17,25): Could not find a declaration file for module 'log4js'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/log4js/lib/log4js.js' implicitly has an 'any' type.
  Try `npm install @types/log4js` if it exists or add a new declaration (.d.ts) file containing `declare module 'log4js';` (7016)
app.ts (18,23): Could not find a declaration file for module 'util'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/util/util.js' implicitly has an 'any' type.
  Try `npm install @types/util` if it exists or add a new declaration (.d.ts) file containing `declare module 'util';` (7016)
app.ts (19,23): Cannot find module 'http'. (2307)
app.ts (20,26): Could not find a declaration file for module 'express'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/express/index.js' implicitly has an 'any' type.
  Try `npm install @types/express` if it exists or add a new declaration (.d.ts) file containing `declare module 'express';` (7016)
app.ts (21,22): Could not find a declaration file for module 'jsonwebtoken'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/jsonwebtoken/index.js' implicitly has an 'any' type.
  Try `npm install @types/jsonwebtoken` if it exists or add a new declaration (.d.ts) file containing `declare module 'jsonwebtoken';` (7016)
app.ts (22,29): Could not find a declaration file for module 'body-parser'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/body-parser/index.js' implicitly has an 'any' type.
  Try `npm install @types/body-parser` if it exists or add a new declaration (.d.ts) file containing `declare module 'body-parser';` (7016)
app.ts (23,29): Could not find a declaration file for module 'express-jwt'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/express-jwt/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/express-jwt` if it exists or add a new declaration (.d.ts) file containing `declare module 'express-jwt';` (7016)
app.ts (25,21): Cannot find name 'require'. (2304)
app.ts (26,23): Could not find a declaration file for module 'cors'. '/home/siddjain/fabric-samples-v13/balance-transfer/node_modules/cors/lib/index.js' implicitly has an 'any' type.
  Try `npm install @types/cors` if it exists or add a new declaration (.d.ts) file containing `declare module 'cors';` (7016)
app.ts (34,21): Cannot find name 'process'. (2304)
app.ts (35,21): Cannot find name 'process'. (2304)
app.ts (56,26): Parameter 'res' implicitly has an 'any' type. (7006)
app.ts (56,31): Parameter 'next' implicitly has an 'any' type. (7006)
app.ts (57,13): Property 'originalUrl' does not exist on type 'RequestEx'. (2339)
    at getOutput (/home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:307:15)
    at /home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:336:16
    at Object.compile (/home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:498:11)
    at Module.m._compile (/home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:392:43)
    at Module._extensions..js (module.js:654:10)
    at Object.require.extensions.(anonymous function) [as .ts] (/home/siddjain/fabric-samples-v13/balance-transfer/typescript/node_modules/ts-node/src/index.ts:395:12)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Function.Module.runMain (module.js:684:10)

How can I fix this?

Also the instructions say that
Node.js v6.9.0 - 6.10.0 ( Node v7+ is not supported )
whereas the instructions for node say that
Node.js v8.4.0 or higher
even the HL Fabric prerequisites say that
If you will be developing applications for Hyperledger Fabric leveraging the Hyperledger Fabric SDK for Node.js, you will need to have version 8.9.x of Node.js installed.

Why does the typescript version not work with v8 of node?

Thanks.


Re: Issue in starting couchdb

adnanchoudhury
 

CouchDB spews out these errors when it does not find one of the three system level databases, (_users, _replicator and _global_changes), especially during the beginning of its instance. These errors stop showing up once these system databases are created by Fabric. They usually don't interfere with Fabric operations.   


On Thu, Nov 29, 2018 at 11:33 AM via Lists.Hyperledger.Org <abhijeetpratapsingh=cedcoss.com@...> wrote:

I am seeing this while i am trying to start couchdb on any peer:


nonode@nohost <0.320.0> -------- chttpd_auth_cache changes listener died database_does_not_exist at mem3_shards:load_shards_from_db/6(line:403) <= mem3_shards:load_shards_from_disk/1(line:378) <= mem3_shards:load_shards_from_disk/2(line:407) <= mem3_shards:for_docid/3(line:91) <= fabric_doc_open:go/3(line:38) <= chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <= chttpd_auth_cache:listen_for_changes/1(line:134)


Issue in starting couchdb

Abhijeet Pratap Singh <abhijeetpratapsingh@...>
 

I am seeing this while i am trying to start couchdb on any peer:


nonode@nohost <0.320.0> -------- chttpd_auth_cache changes listener died database_does_not_exist at mem3_shards:load_shards_from_db/6(line:403) <= mem3_shards:load_shards_from_disk/1(line:378) <= mem3_shards:load_shards_from_disk/2(line:407) <= mem3_shards:for_docid/3(line:91) <= fabric_doc_open:go/3(line:38) <= chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <= chttpd_auth_cache:listen_for_changes/1(line:134)


Re: New Project Proposal: Fabric Desktop

Alessandro Sorniotti
 

Personally I'd like to learn more about this project: have you considered a playback (https://wiki.hyperledger.org/projects/fabric/playbacks) to let the community know more about it and start a discussion?

Thanks!
Ale

On Thu, 29 Nov 2018, at 10:29 AM, Yi DENG wrote:
Dear Fabric Maintainers and All, 

It is Yi. Recently, we developed a desktop app for Fabric. It is
general-purpose, in other words, an API tool with GUI. We would like to
contribute it to Hyperledger. 

Right now, TSC is discussing and would like to know how Fabric
maintainers think about this. Things like its relationship with Fabric;
if it should be a top-level project or sub-project of Fabric; and how to
maintain projects like this. It is pleased to hear from you. 

TSC Dicsussion Details:
https://lists.hyperledger.org/g/tsc/topic/new_project_proposal_fabric/28046677?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28046677
 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit
( https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit )

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

----

Yi DENG

 

Senior Software Engineer - Yonyou



New Project Proposal: Fabric Desktop

Yi DENG
 

Dear Fabric Maintainers and All, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. 
We would like to contribute it to Hyperledger. 

Right now, TSC is discussing and would like to know how Fabric maintainers think about this. Things like its relationship with Fabric; if it should be a top-level project or sub-project of Fabric; and how to maintain projects like this. It is pleased to hear from you. 

TSC Dicsussion Details:
https://lists.hyperledger.org/g/tsc/topic/new_project_proposal_fabric/28046677?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,28046677
 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop


----

Yi DENG

 

Senior Software Engineer - Yonyou


Looking for interesting use cases and their stories

Don Li <lichunshen84@...>
 

Hi all,

I'm interested in people and companies that have done quite a few or been working on some interesting use cases that leverage the Hyperledger Fabric platform to share their stories.
And it would be nice if they can discuss some of the challenges or unintended discovery or new learning and/or development of cool features or functionality ( more on the chaincode coding side, another way to put it, advanced functionality of chaincode, particularly in Node.js ). 

We know appending textual and/or non-textual data onto a Fabric chain (ledgers on peers) and even creating re-usable code are fairly easy, but for many real world business applications they may be more demanding.  For me, I'd like to anticipate future needs and try to figure out how to solve complex problems before actually working on them, thus, to increase the odds of a successful completion of such a project or at least contribute to it efficiently.

Many thanks.

(Don) Chunshen Li


Backup and Restore: HyperLedger Fabric

Dmello, Melwin <melwin.dmello@...>
 

Hello,

 

I need information on how to back-up and restore a Hyperledger Fabric network.

The best I could find is this https://jira.hyperledger.org/browse/FAB-3364

 

Can you please guide me a resource which will help me in backup/restore of the entire network.

I understand that there are various components involved like the Orderer, Peer, CA.

However, there should be some backup strategy/procedure which addresses this area.

 

Thanks & Regards,

Melwin Dmello

Software Developer

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.


Re: Running HLF on shared VM

John Sheehan
 

On 27/11/2018, Sunil Suseelan <sunil.suseelan@...> wrote:
Hello Folks,



Is there any document/tutorial that guides us on how to run HyperLedger
Fabric on multiple VM's



http://www.oracle.com/
Sunil Suseelan | Associate Presales Consultant

Phone: HYPERLINK "tel:+40213678176"+918898549399
Oracle Sales Consulting Centres - MiddelWare

Oracle India | Krishna Magnum | 4th Floor | Bangalore-560076

_____





http://my.oracle.com/go/epc






Visit the SCC website at http://my.oracle.com/go/epc

_____

http://www.oracle.com/commitment

Oracle is committed to developing practices and products that help protect
the environment








How to get the ledger height of channel in real time? #fabric-sdk-node

andychen.chen@...
 

As we know, one channel can have multiple peers, and when we query ledger height , we need to specify one peer in the channel, but if this peer's ledger is not up to date(e.g. not a leader peer, network issue,sync delay),we will not get the latest ledger data.

Obviously, it's not good to do a circle check on all peers in channel to get the ledger data which has the biggest height.
Is there any other way to achieve this? e.g. can we know which peer is leader peer in a channel in fabric sdk? suppose leader peer should have the latest ledger data.

6421 - 6440 of 11510