Date   

Re: Devcon in Prague

mike.ward@...
 

I’ll be attending for R3 on Wed and Thu.

Mike

Sent from my mobile. Please excuse the tpyos and odd worlds.

On Oct 24, 2018, at 5:06 AM, Brian Behlendorf <bbehlendorf@...> wrote:

That's great.  And yes my ask was of anyone following the list, not just TSC members.  :)  See you in SG.

Brian

On 10/23/18 6:47 PM, Duncan Johnston-Watt wrote:
Brian

I appreciate that we are not TSC members but FWIW myself and Kai Davenport will be at SG Fintech Festival where we will be delivering a two day workshop as part of their industry events program Nov 15&16 - https://fintechfestival.sg/festival-line-up/industry/ - which we will be promoting shortly.

If you or Julian know of folk locally in SG who would benefit from this but workshop who don't have the budget please connect us and we will give them a discount code.

Best

Duncan

On Wed, Oct 24, 2018 at 2:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
Who will be at DevCon in Prague in two weeks?  I'll be there but only
Thursday the 1st through Sunday morning.  Happy to meet up with anyone
there.  We are also doing a Meetup on Friday night:
https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will
be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG
Fintech Week the 11th-14th?

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf






--


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Invitation: Technical Steering Committee (TSC) @ Weekly from 07:00 to 08:00 on Thursday (PDT) (tsc@lists.hyperledger.org)

Ry Jones
 

Please note: the Zoom URL and meeting ID has changed.

On Fri, Oct 26, 2018 at 5:50 PM Ry Jones <rjones@...> wrote:

Technical Steering Committee (TSC)

When
Weekly from 07:00 to 08:00 on Thursday Pacific Time - Los Angeles
Where
Calendar
Who
(Guest list has been hidden at organizer's request)


Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs

Going (tsc@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.



--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Invitation: Technical Steering Committee (TSC) @ Weekly from 07:00 to 08:00 on Thursday (PDT) (tsc@lists.hyperledger.org)

Ry Jones
 

Technical Steering Committee (TSC)

When
Weekly from 07:00 to 08:00 on Thursday Pacific Time - Los Angeles
Where
https://zoom.us/my/hyperledger.community.backup (map)
Calendar
tsc@...
Who
(Guest list has been hidden at organizer's request)


Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community.backup

Or iPhone one-tap :
US: +16699006833,,6223336701# or +16465588656,,6223336701#
Or Telephone:
Dial(for higher quality, dial a number based on your current location):
US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
Meeting ID: 622-333-6701
International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs

Going (tsc@...)?   All events in this series:   Yes - Maybe - No    more options »

Invitation from Google Calendar

You are receiving this courtesy email at the account tsc@... because you are an attendee of this event.

To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar.

Forwarding this invitation could allow any recipient to modify your RSVP response. Learn More.


Re: Test net thinking

Christopher Ferris <chris.ferris@...>
 

Interesting that Casey thinks of long-running tests, performance, chaos, etc. I always think of a testnet as a place where devs can kick the tires without having to do the heavy lifting of setting up a network themselves.

For the long-running tests, etc. we have nightly runs and we are gearing up a weekly as well that will be long running test that has kitchen sinks thrown at it and stuff. Not a large environment, but more than what we do for the merge and nightly CI.

IBM also runs a series of long running tests leading up to a release on our platforms. We do share the results indirectly and it would be nice if they were just public, frankly (this is me speaking not for IBM but as a member of the community). We are working on an ability to spin up networks arbitrary complexity and scale, so that tests can be run. It would be nice to have that running in the community, but again, not as a test net for users as much as for what Casey was advocating for.

Cheers

Chris


On Fri, Oct 26, 2018 at 10:24 AM Middleton, Dan <dan.middleton@...> wrote:

Tldr: We only scale this if we have multiple companies hosting. What kind of HL support is required to facilitate that?

 

I agree with Chris that at least for native contracts like transaction families and chaincode our projects have scripts so developers can launch mini environments on their laptops (in sawtooth it’s basically `docker-compose up`). For on-chain smart contracts like burrow, sabre, and so forth developers might appreciate a running testnet to deploy to.

 

I kind of expected Casey to come in along those lines, so it’s really helpful to read his priority for stress testing infrastructure.

 

Last year, running up to our 1.0 launch, the sawtooth team found they needed to automate the long running tests and associated cloud deployments. We’ve taken to calling these our LR networks.

 

LRs are typically 10 node networks + load generation and stats collections for 1 to 7 days. These LR networks have been invaluable to testing features before issuing PRs.

 

This stress testing is not cheap though. It’s one thing to pay for an idle instance and it’s another to pay for 10 fully utilized instances.

And as we are normally testing nightly builds along with experimental branches etc., it’s really more like a multiple of 10.

 

Based on the CNCF readme I’d bet the sawtooth project alone could easily consume all their credits. CNCF, then is probably a good start but not a complete solution to support all the HL projects. Similarly any direct budget estimate for infrastructure would need to be on the order of $10k/month/project which is probably not tenable.

 

For sawtooth, we are looking at a crawl, walk, run with the community to expand from LR nets to larger longer testnets. Start with some machines provided by companies x, y, z and then add more users/instances. Actually demonstrating that multiple companies can attach to a running network is a highly valuable exercise. We’re shooting to have the crawl version of the testnet up imminently. In getting that underway we may discover some of the administrative or other challenges that HL can solve in subsequent iterations.

 

Regards,
Dan

 

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Friday, October 26, 2018 at 12:06 AM
To: Casey Kuhlman <casey@...>
Cc: Christopher Ferris <chris.ferris@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Test net thinking

 

For people who are interested in CNCF services, the gatekeeper is CNCF, not Hyperledger.

 

 

Following the template, file an issue, make your case. Note it is a limited resource and priority is given to CNCF projects. I've talked to Dan Kohn a couple of times and he wants to use the resource as much as possible.

 

Ry

 

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman via Lists.Hyperledger.Org <casey=monax.io@...> wrote:

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle. 

 

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

 

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).

--

Ry Jones

Community Architect, Hyperledger

Chat: @ry


Re: Agenda for October 25th, 2018

Ry Jones
 

Minutes:

Hyperledger Project

Technical Steering Committee (TSC) Meeting

October 25, 2018 (7:00am - 8:00am PT)

via Zoom


TSC Members

Arnaud Le Hors


Baohua Yang

Yes

Binh Nguyen


Christopher Ferris

Yes

Dan Middleton

Yes

Hart Montgomery

Yes

Kelly Olson

Yes

Mark Wagner

Yes

Mic Bowman

Yes

Nathan George

Yes

Silas Davis

Yes


Resources:


Event Reminders


Quarterly project updates

  • Hyperledger Iroha update

    • Update is read into the record

    • Q: is there contributor churn? How is diversity?

    • A: No churn, low diversity

    • Dan points out there are no Iroha meetings on the Community Calendar.

    • Comment: too many chat forums (Telegram, Chat, Gitter)

    • Reply: bots are used to mirror contents of Telegram to Chat

  • November 1st:  Hyperledger Composer update


Quarterly WG updates

  • Technical WG China update

    • Update is read into the record

    • Comment: why a testnet?

    • Reply: Need place to dogfood, or run a proof-of-contribution token as an example

    • Comment: could more active Technical Ambassadors help?

    • Reply: Hyperledger is trying to recruit more

    • Comment: Hyperledger doesn’t fund meetups directly

    • Further comment: Hyperledger does provide some assistance for food when getting started, but not space rental

  • November 1st:  Training and Education WG update


Crypto-lib

  • Proposal

  • Q: Mic: what is the commitment from projects to incorporate crypto-lib?

  • A: Hart: none

  • A: Nathan: Indy wants to use ASAP

    • Q: would depending on crypto-lib hurt our process of 1.0?

    • A: Dan: no reason it would hurt

  • A: Dan: Sawtooth is interested in adopting, is actively involved in develop to ensure Sawtooth can use it

  • A: Silas: Burrow wants to use it

  • A: Chris: Fabric doesn’t know. There would need to be Go bindings developed; it would be a post 2.0 item

  • A: Salakhiev: Iroha: no plans, would consider in future

  • Comment: the governance structure is unique

    • A robust discussion follows and moved to the mailing list


Testnet discussion/proposal

  • Deferred to next week


--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Re: Test net thinking

Middleton, Dan <dan.middleton@...>
 

Tldr: We only scale this if we have multiple companies hosting. What kind of HL support is required to facilitate that?

 

I agree with Chris that at least for native contracts like transaction families and chaincode our projects have scripts so developers can launch mini environments on their laptops (in sawtooth it’s basically `docker-compose up`). For on-chain smart contracts like burrow, sabre, and so forth developers might appreciate a running testnet to deploy to.

 

I kind of expected Casey to come in along those lines, so it’s really helpful to read his priority for stress testing infrastructure.

 

Last year, running up to our 1.0 launch, the sawtooth team found they needed to automate the long running tests and associated cloud deployments. We’ve taken to calling these our LR networks.

 

LRs are typically 10 node networks + load generation and stats collections for 1 to 7 days. These LR networks have been invaluable to testing features before issuing PRs.

 

This stress testing is not cheap though. It’s one thing to pay for an idle instance and it’s another to pay for 10 fully utilized instances.

And as we are normally testing nightly builds along with experimental branches etc., it’s really more like a multiple of 10.

 

Based on the CNCF readme I’d bet the sawtooth project alone could easily consume all their credits. CNCF, then is probably a good start but not a complete solution to support all the HL projects. Similarly any direct budget estimate for infrastructure would need to be on the order of $10k/month/project which is probably not tenable.

 

For sawtooth, we are looking at a crawl, walk, run with the community to expand from LR nets to larger longer testnets. Start with some machines provided by companies x, y, z and then add more users/instances. Actually demonstrating that multiple companies can attach to a running network is a highly valuable exercise. We’re shooting to have the crawl version of the testnet up imminently. In getting that underway we may discover some of the administrative or other challenges that HL can solve in subsequent iterations.

 

Regards,
Dan

 

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Friday, October 26, 2018 at 12:06 AM
To: Casey Kuhlman <casey@...>
Cc: Christopher Ferris <chris.ferris@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Test net thinking

 

For people who are interested in CNCF services, the gatekeeper is CNCF, not Hyperledger.

 

 

Following the template, file an issue, make your case. Note it is a limited resource and priority is given to CNCF projects. I've talked to Dan Kohn a couple of times and he wants to use the resource as much as possible.

 

Ry

 

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman via Lists.Hyperledger.Org <casey=monax.io@...> wrote:

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle. 

 

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

 

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).

--

Ry Jones

Community Architect, Hyperledger

Chat: @ry


Re: Test net thinking

Ry Jones
 

For people who are interested in CNCF services, the gatekeeper is CNCF, not Hyperledger.


Following the template, file an issue, make your case. Note it is a limited resource and priority is given to CNCF projects. I've talked to Dan Kohn a couple of times and he wants to use the resource as much as possible.

Ry


On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman via Lists.Hyperledger.Org <casey=monax.io@...> wrote:
From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle. 

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Re: Test net thinking

Duc Trinh <duc.m.trinh@...>
 

Both would useful. However, if there is a need to prioritize, I would like to throw a +1 for standing up a test net - especially for Fabric. I think the motivations for having a test are similar to what has been articulated for Stellar (@ https://www.stellar.org/developers/guides/concepts/test-net.html)

To keep hosting costs in check, HL can reset the network periodically (again, similar to what Stellar does).

Cheers,
Duc

On 10/25/18, 11:13 AM, "tsc@... on behalf of David Huseby" <tsc@... on behalf of dhuseby@...> wrote:

I think all of you are making very good points. There seem to be two
camps of "itches":

1) chaincode and developer UX focused "let me quickly test this".
2) developer/integration testing of an instance of a blockchain for
purposes of running it through the gamut of tests and letting it soak
to test stability over time.

I draw the lines there because addressing #1 is not really a concern
of test nets. I would think that something like a universal HL
Composer would be the way to go. Or better yet, a plugin for VSCode
or Vim/Emacs that allows for quick deployment of chaincode to a
running blockchain and then has useful hooks for testing. Again, this
is more developer interfacing than test nets and outside of the scope
of the proposal.

#2 is absolutely test nets and I think the correct way to address this
is for HL to pay for managed Kubernetes infrastructure that teams can
use Kubernetes configs and/or Helm charts to deploy a blockchain
network on for whatever they need to do, be it chaos testing, load
testing, or just a soak test. We have already begun the effort to
standardize Kubernetes configs/Helm charts in several projects. The
HL Cello meeting is where those people have been congregating and the
next step there is to have the different blockchain projects start
publishing official, composable configs/charts as part of their build
process and published outputs. This would make it trivial for a
developer/tester to "kubectl apply fabric-1.3.yaml" on Amazon EKS or
GCE or whatever Kubernetes infrastructure we set up.

I prefer Amazon because it has a very good cost predictor calculator
that can be used to see how much the tests would cost to run and it
would help with our accounting.

As for HL managment, my plan is that we only have very minimal
management that is focused around giving out credentials to use the
Kubernetes infrastructure and handling re-embursements for the bills.
I think it should be entirely upon the user/tester to handle spinning
up/down their blockchain. IMO HL shouldn't be in the business of
being IT for everybody who wants to spin up a blockchain for testing.
The cost of that would be huge and the time spent on that would
greatly impact our ability to grow the community in all other ways.

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

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman <casey@...> wrote:
>
> From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle.
>
> While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.
>
> My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
> ____________________________________
>
> Casey Kuhlman, Monax
> CEO
> Site: https://monax.io
> Twitter: @monaxhq, @compleatang
> Email: casey@...
> Phone (US): +1-423-523-9531; (UK): +44-75-073-96359
> ____________________________________
>
>
> On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:
>>
>> Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
>> Having a testnet does nothing to improve that experience IMNSHO.
>>
>> Chris
>>
>> On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
>>>
>>> Chris,
>>>
>>> I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may.
>>>
>>> I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.
>>>
>>> There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.
>>>
>>> Sincerely,
>>> Dan
>>>
>>>
>>> On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
>>>>
>>>> I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?
>>>>
>>>> I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.
>>>>
>>>> download fabric-samples repo, images and binaries (one click)
>>>> cd first-network
>>>> byfn.sh up
>>>>
>>>> three commands and you have it running on your laptop.
>>>>
>>>> Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?
>>>>
>>>> I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.
>>>>
>>>> Chris
>>>>
>>>> On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
>>>>>
>>>>> Hi TSC,
>>>>>
>>>>> I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:
>>>>>
>>>>> The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do.
>>>>>
>>>>> The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval.
>>>>>
>>>>> I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Dave
>>>>> --
>>>>> ---
>>>>> David Huseby
>>>>> Security Maven, Hyperledger
>>>>> The Linux Foundation
>>>>> +1-206-234-2392
>>>>> dhuseby@...
>>>
>>>
>>>
>>> --
>>> Dan Selman
>>> CTO, Clause Inc.
>>> @danielselman
>>>
>>


Re: Test net thinking

David Huseby <dhuseby@...>
 

I think all of you are making very good points. There seem to be two
camps of "itches":

1) chaincode and developer UX focused "let me quickly test this".
2) developer/integration testing of an instance of a blockchain for
purposes of running it through the gamut of tests and letting it soak
to test stability over time.

I draw the lines there because addressing #1 is not really a concern
of test nets. I would think that something like a universal HL
Composer would be the way to go. Or better yet, a plugin for VSCode
or Vim/Emacs that allows for quick deployment of chaincode to a
running blockchain and then has useful hooks for testing. Again, this
is more developer interfacing than test nets and outside of the scope
of the proposal.

#2 is absolutely test nets and I think the correct way to address this
is for HL to pay for managed Kubernetes infrastructure that teams can
use Kubernetes configs and/or Helm charts to deploy a blockchain
network on for whatever they need to do, be it chaos testing, load
testing, or just a soak test. We have already begun the effort to
standardize Kubernetes configs/Helm charts in several projects. The
HL Cello meeting is where those people have been congregating and the
next step there is to have the different blockchain projects start
publishing official, composable configs/charts as part of their build
process and published outputs. This would make it trivial for a
developer/tester to "kubectl apply fabric-1.3.yaml" on Amazon EKS or
GCE or whatever Kubernetes infrastructure we set up.

I prefer Amazon because it has a very good cost predictor calculator
that can be used to see how much the tests would cost to run and it
would help with our accounting.

As for HL managment, my plan is that we only have very minimal
management that is focused around giving out credentials to use the
Kubernetes infrastructure and handling re-embursements for the bills.
I think it should be entirely upon the user/tester to handle spinning
up/down their blockchain. IMO HL shouldn't be in the business of
being IT for everybody who wants to spin up a blockchain for testing.
The cost of that would be huge and the time spent on that would
greatly impact our ability to grow the community in all other ways.

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

On Thu, Oct 25, 2018 at 8:28 AM Casey Kuhlman <casey@...> wrote:

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle.

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
____________________________________

Casey Kuhlman, Monax
CEO
Site: https://monax.io
Twitter: @monaxhq, @compleatang
Email: casey@...
Phone (US): +1-423-523-9531; (UK): +44-75-073-96359
____________________________________


On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:

Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris

On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:

Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may.

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:

I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:

Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do.

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval.

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year.

Thoughts?

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


--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Casey Kuhlman
 

From the burrow perspective, we'd be very interested in test networks to actually run testing in terms of performance testing, chaos testing, soak testing, long-lived network testing which a simple CI run post merge cannot really handle. 

While I think both Dan and Chris make valid points in terms of positioning the test networks as things to help users get started faster, our interest from the burrow team is less in that area and more in having an HL managed infrastructure which can help us.... test.

My point, and the reason that Silas brought this up a few months ago to the TSC is that from a testing and performance perspective I think we could do much better as a community. CCNF and the Kubernetes project have a super clean and easy to approach CI system that made it dead simple for me as a contributor when I started making contributions to helm. From my perspective we'd be very interested to see if HL could coordinate with CCNF (as Ry mentioned on RocketChat).
____________________________________

Casey Kuhlman, Monax
CEO
Email: casey@... 
Phone (US): +1-423-523-9531(UK): +44-75-073-96359
____________________________________


On Thu, Oct 25, 2018 at 4:03 PM Christopher Ferris <chris.ferris@...> wrote:
Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris

On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Christopher Ferris <chris.ferris@...>
 

Dan, yes, but my response to that would be that Fabric should improve its UX around deploying and engaging chaincode/smart contract.
Having a testnet does nothing to improve that experience IMNSHO.

Chris


On Thu, Oct 25, 2018 at 10:18 AM Dan Selman <dan@...> wrote:
Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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



--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Dan Selman
 

Chris,

I think you raise some very valid points regarding operating a test net. I'd like to inject an end user perspective if I may. 

I think Ethereum wins from an ease of use perspective because people can easily write a smart contract and deploy it to a test network. That's what the vast majority of developers want to get done when they first encounter blockchain and IMO that is where Fabric (and others) fall down. HLF v1.3 has made it (relatively) easy to *start* the network on your laptop, but once you actually want to deploy chaincode and interact with it, it is a whole different story: you start hacking on fabcar and trying to understand how ./startFabric.sh, enrollAdrmin.js, registerUser.js, hlf-key-store, docker etc all work. Contrast with using http://remix.ethereum.org running in the browser, or connected to https://infura.io or https://kaleido.io for writing your first Solidity code.

There's an opportunity to do something similar to remix using the Composer Playground connected to a test net which is worth exploring imo. I don't know if that should be the remit of HL/TSC but there's clearly a need for something like that to attract more developers.

Sincerely,
Dan


On Thu, Oct 25, 2018 at 2:54 PM Christopher Ferris <chris.ferris@...> wrote:
I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris

On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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



--
Dan Selman
CTO, Clause Inc.
@danielselman


Re: Test net thinking

Christopher Ferris <chris.ferris@...>
 

I think that we need to consider what we think a "test net" is. Is it a whole network that a developer spins up themselves? Is it a pre-existing network that we have launched and that developers can use to deploy a smart contract and kick the tires? Is it permissioned? Permissionless? What are the implications? Will there be likelihood of noisy neighbor situations? Crypto Kitties? Who will monitor the experience? What if it gets really bogged down? Who is monitoring that it is running? Will users walk away from a bad experience with a bad taste in their mouths? How will the experience reflect on the project and the organization?

I don't disagree that we want to make it dead simple to engage with the various projects. However, I can say that for Fabric, the process could not be simpler.

download fabric-samples repo, images and binaries (one click)
cd first-network
byfn.sh up

three commands and you have it running on your laptop.

Could we create some helm charts that could be used to deploy our various projects to K8s? Let people deal with finding the compute however they like (maybe point at alternatives) but we don't host/pay?

I ask because I really don't understand what problem we think we are solving with a test net, nor do I believe that we have considered the broader implications of running a cloud service on a volunteer basis.

Chris


On Wed, Oct 24, 2018 at 5:56 PM David Huseby <dhuseby@...> wrote:
Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


Agenda for October 25th, 2018

Todd Benzies <tbenzies@...>
 

  • Event Reminders

  • Quarterly project updates
    • Hyperledger Iroha update
    • November 1st:  Hyperledger Composer update
  • Quarterly WG updates
    • Technical WG China update
    • November 1st:  Training and Education WG update
  • crypto-lib proposal proposal (Hart Montgomery)
  • Testnet discussion/proposal (Dave Huseby)

--
Todd Benzies
Sr. Director, Program Management & Operations
The Linux Foundation
+1 (415) 412-0310 (m)


Test net thinking

David Huseby <dhuseby@...>
 

Hi TSC,

I had a discussion with Ry this week while manning the booth at ATO in Raleigh and we both think the right way to go is a two pronged approach:

The first prong will be to engage with the free kubernetes hosting being paid for by (I think) the CNCF project. Ry knows more about it than I do. 

The second prong would be to set aside some budget to cover the cost of people running networks on Amazon EKS. We could set some rule like we cover the cost up to $200 for the first month with an opportunity to get additional months with approval. 

I agree with Chris and Ry and I’m concerned about the human overhead of trying to run test nets for people. I think the best compromise is to just cover the bills for people spinning up test networks on hosted kubernetes platforms. The oversight needs to be an easy application and approval process as well as an easy renewal process. I was thinking that $20k would be enough to cover. That’s at least 10 networks per month for a year. 

Thoughts?

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


Re: Devcon in Prague

Brian Behlendorf
 

That's great.  And yes my ask was of anyone following the list, not just TSC members.  :)  See you in SG.

Brian

On 10/23/18 6:47 PM, Duncan Johnston-Watt wrote:
Brian

I appreciate that we are not TSC members but FWIW myself and Kai Davenport will be at SG Fintech Festival where we will be delivering a two day workshop as part of their industry events program Nov 15&16 - https://fintechfestival.sg/festival-line-up/industry/ - which we will be promoting shortly.

If you or Julian know of folk locally in SG who would benefit from this but workshop who don't have the budget please connect us and we will give them a discount code.

Best

Duncan

On Wed, Oct 24, 2018 at 2:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
Who will be at DevCon in Prague in two weeks?  I'll be there but only
Thursday the 1st through Sunday morning.  Happy to meet up with anyone
there.  We are also doing a Meetup on Friday night:
https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will
be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG
Fintech Week the 11th-14th?

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf






--


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: Devcon in Prague

Duncan Johnston-Watt
 

Brian

I appreciate that we are not TSC members but FWIW myself and Kai Davenport will be at SG Fintech Festival where we will be delivering a two day workshop as part of their industry events program Nov 15&16 - https://fintechfestival.sg/festival-line-up/industry/ - which we will be promoting shortly.

If you or Julian know of folk locally in SG who would benefit from this but workshop who don't have the budget please connect us and we will give them a discount code.

Best

Duncan


On Wed, Oct 24, 2018 at 2:35 AM Brian Behlendorf <bbehlendorf@...> wrote:
Who will be at DevCon in Prague in two weeks?  I'll be there but only
Thursday the 1st through Sunday morning.  Happy to meet up with anyone
there.  We are also doing a Meetup on Friday night:
https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will
be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG
Fintech Week the 11th-14th?

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf







Devcon in Prague

Brian Behlendorf
 

Who will be at DevCon in Prague in two weeks?  I'll be there but only Thursday the 1st through Sunday morning.  Happy to meet up with anyone there.  We are also doing a Meetup on Friday night: https://www.meetup.com/Hyperledger-Prague/events/255766163/  Marta will be there I believe all week.  Let me know if you'll be there.

Or in Hong Kong next week for HK Fintech week?  Or Singapore for SG Fintech Week the 11th-14th?

Brian

--
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Hyperledger Iroha Quarterly Update Due #tsc-project-update - Thu, 10/25/18 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder:
Hyperledger Iroha Quarterly Update Due #tsc-project-update

When:
Thursday, 25 October 2018

Description:
The Hyperledger Iroha project update to the TSC was due October 22, 2018, and it will be presented to the TSC on October 25, 2018. Please review prior to the meeting and bring your questions.

View Event.


Hyperledger Training and Education WG Quarterly Update Due #tsc-wg-update - Thu, 10/25/18 #tsc-wg-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder:
Hyperledger Training and Education WG Quarterly Update Due #tsc-wg-update

When:
Thursday, 25 October 2018

Description:
The Hyperledger Training and Education WG update to the TSC was due October 22, 2018, and it will be presented to the TSC on October 25, 2018. Please review prior to the meeting and bring your questions.

View Event.

2061 - 2080 of 3871