CI/CD and testnets proposal for discussion tomorrow


Dave Huseby <dhuseby@...>
 

Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

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


Shawn Amundson
 

Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

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


Casey Kuhlman
 

Dave, 

Can you elaborate on the proposed direction of travel regarding testnets? Is the idea that HL will run a CE instance of Gitlab in some infrastructure or that gitlab.com will be the instance? If the latter where are the runners going to live infrastructure wise? If in gitlab.com's infrastructure that would be fine for CI from our (Burrow's) perspective, but won't be ideal for testnets due to CI timeouts. 

For burrow we have extensive helm charts, gitlab CI configs, and testnet / stressnet mechanisms built already which we operate from Monax's self hosted Gitlab in our Kubernetes cluster. So in general this direction of travel gets a ++ from me. If we (burrow maintainers) have access to running testnets / stressnets in a Kubernetes cluster that's not Monax's via Gitlab CI we would be very happy campers indeed.

Thanks in advance,
~Casey

On Wed, Mar 27, 2019, 22:12 Shawn Amundson <amundson@...> wrote:
Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

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


Dave Huseby <dhuseby@...>
 

To Shawn,

This idea is based off of what Sovrin has set up for Ursa. Mike Lodder had done the bulk of the legwork here and deserves most of the credit...unless you guys hate the proposal, then blame me, it was my idea to propose to take this HL-wide. Ursa is hosted on HL github, uses HL Jira/Confluence, and now uses a temporary Gitlab (CE version) running on Sovrin infrastructure. This is after Sovrin spent months trying to take the existing HL CI/CD stuff and failing to modify it for Indy and Ursa.

To Casey,

In the proposal I say that the best part of Gitlab is that runners can be contributions from the community. HL will run a couple of shared runners to make sure that projects without community provided runners will have a minimum level of CI/CD capabilities.  We will run the CE version because all we need is AD/LDAP integration so we can use LFID's as well as the CI/CD pipeline. In summary, the gitlab would be running on HL infrastructure, the runners on community contributed hardware.  

I just set up a spare machine as a runner for the Ursa builds and plugged it into the Sovrin Gitlab in just a few minutes.

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


On Wed, Mar 27, 2019 at 3:42 PM Casey Kuhlman <casey@...> wrote:
Dave, 

Can you elaborate on the proposed direction of travel regarding testnets? Is the idea that HL will run a CE instance of Gitlab in some infrastructure or that gitlab.com will be the instance? If the latter where are the runners going to live infrastructure wise? If in gitlab.com's infrastructure that would be fine for CI from our (Burrow's) perspective, but won't be ideal for testnets due to CI timeouts. 

For burrow we have extensive helm charts, gitlab CI configs, and testnet / stressnet mechanisms built already which we operate from Monax's self hosted Gitlab in our Kubernetes cluster. So in general this direction of travel gets a ++ from me. If we (burrow maintainers) have access to running testnets / stressnets in a Kubernetes cluster that's not Monax's via Gitlab CI we would be very happy campers indeed.

Thanks in advance,
~Casey

On Wed, Mar 27, 2019, 22:12 Shawn Amundson <amundson@...> wrote:
Sounds cool. Perhaps we could do an evaluation period were projects can evaluate using the gitlab setup to determine if it is sufficient to replace existing tooling, with the intent to report back on the experience to the TSC. Is Ursa already using this setup? How much effort would it take from HL staff to do such a evaluation period?

-Shawn

On Wed, Mar 27, 2019 at 4:04 PM Dave Huseby <dhuseby@...> wrote:
Hi TSC,

I put together a summary with details on what I propose we do to rework the HL CI/CD pipeline. The proposal can be found here: https://wiki.hyperledger.org/display/HYP/Software+Delivery

As usual, comment there, discuss here.

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