afzal442 / keptn-pg-killerway

This repo contains keptn CD walkthrough tutorial to understand the out-of-the-box demo.
https://agardnerit.github.io/thekindkeptn/full-tour.html
MIT License
8 stars 5 forks source link

Get rid of GitHub, use gitea #60

Open christian-kreuzberger-dtx opened 2 years ago

christian-kreuzberger-dtx commented 2 years ago

With the introduction of resource-service in Keptn 0.16 the git upstream became mandatory, which is why GitHub is mandatory for this tutorial.

IMO this just adds an extra step that's confusing for new users, and this is why we published the keptn-gitea-provisioner-service.

In order to use it with Keptn 0.17, the following things have to be done:

  1. Install gitea
  2. Install keptn-gitea-provisioner-service
  3. Install Keptn and configure it to use the gitea-provisioner-service

We have information available on how this works here: https://github.com/keptn-sandbox/keptn-gitea-provisioner-service#quickstart

Acceptance Criteria

agardnerIT commented 2 years ago

I disagree. GitHub is widely used and known whereas Gitea is not. It also bloats the installation which is a real issue as we are resource constrained for this tutorial.

Using GitHub.com shows how to use Keptn is a real world scenario whereas Gitea feels too "demo-mode" and would lead to lots of "well Keptn works with this thing called Gitea but does it work with [GitHub | Gitlab ... etc. ]" questions in Slack.

In my experience with Keptn users, the issue isn't using GitHub, it's the fact that Keptn mandates an empty repo - meaning a brand new repo for every test project. I'd rather see the development time, tutorial maintenance effort and issue handling go towards progressing Keptn's folder based structure (which AFAIK will allow non-empty folder usage). Rather than yet-another-dependency on a niche tool like Gitea.

Overall I just don't see the net benefit (in this particular case for using Gitea over GitHub).

Perhaps the creation and use of a GitHub.com provisioner is the solution here?

This is just my opinion though so I'll wait for others to chime in.

christian-kreuzberger-dtx commented 2 years ago

Hi Adam,

I'm absolutely on your side regarding being resource constraint.

Though I need to heavily disagree with the Gitea vs. GitHub part. Depending on what tools you use, you could make a similar comparision about GitHub vs. BitBucket or Azure DevOps or GitLab.

The main feature that you want to demonstrate with Keptn is that it stores project-related files in Git (not GitHub), and that the user has full control over all files. In fact, we can even let the user access Gitea and take a look themselves.

Last but not least, and I can confirm this from many people I have spoken too: Having to create a token on GitHub (as well as a repo) is way too much for a demo/tutorial.

Perhaps the creation and use of a GitHub.com provisioner is the solution here?

Would love to see this, also for other providers, and then the user can choose.

agardnerIT commented 1 year ago

I'm looking into this now.

Existing (GitHub based) tutorial is 81% full on disk at the Installation complete message.

$ df -H
Filesystem      Size  Used Avail Use% Mounted on
udev            1.1G     0  1.1G   0% /dev
tmpfs           209M  1.3M  208M   1% /run
/dev/vda1        11G  8.3G  2.0G  81% /
tmpfs           1.1G     0  1.1G   0% /dev/shm
tmpfs           5.3M     0  5.3M   0% /run/lock
tmpfs           1.1G     0  1.1G   0% /sys/fs/cgroup
/dev/loop0       65M   65M     0 100% /snap/core20/1081
/dev/loop1       71M   71M     0 100% /snap/lxd/21545
/dev/loop2       34M   34M     0 100% /snap/snapd/13170
/dev/vda15      110M  5.5M  104M   5% /boot/efi
/dev/loop3       47M   47M     0 100% /snap/snapd/15534
/dev/loop4       66M   66M     0 100% /snap/core20/1434
/dev/loop5       72M   72M     0 100% /snap/lxd/22753
overlay          11G  8.3G  2.0G  81% /var/lib/docker/overlay2/c007442bad14c9986fc517c3613f6858eaa1bfb795dc37a9c755c949f0a23bda/merged
overlay          11G  8.3G  2.0G  81% /var/lib/docker/overlay2/9344c51e8577cdc952fb2bfb9994fcdc31e2e9cf4660e15893955278c1633768/merged

Gitea took over 3 minutes to startup:

$ kubectl -n gitea get pods
NAME                               READY   STATUS    RESTARTS   AGE
svclb-gitea-http-46hg2             1/1     Running   0          3m23s
gitea-memcached-7b44bc5f74-rthkk   1/1     Running   0          3m23s
gitea-postgresql-0                 1/1     Running   0          3m23s
gitea-0                            1/1     Running   0          3m23s

Update. I don't think this is realistic as it would mean adding another 3 minutes to the demo startup time.

You've convinced me that a self-contained demo with no GitHub dependency is a good thing, but we need to look for a different solution until Gitea starts quicker.

Due to this issue, Keptn takes about 3mins to startup so Keptn + Gitea would be 6 minutes (or 10% of the users total time on environment).

Postgresql

Every 2.0s: kubectl -n gitea get pods                                                     ubuntu: Sun Jul 31 21:48:59 2022

NAME                               READY   STATUS     RESTARTS   AGE
svclb-gitea-http-p8n9b             1/1     Running    0          2m7s
gitea-memcached-7b44bc5f74-ql9fl   1/1     Running    0          2m7s
gitea-0                            0/1     Init:2/3   0          2m8s
gitea-postgresql-0                 1/1     Running    0          2m8s

Every 2.0s: kubectl -n gitea get pods                                                     ubuntu: Sun Jul 31 21:50:07 2022

NAME                               READY   STATUS    RESTARTS   AGE
svclb-gitea-http-p8n9b             1/1     Running   0          3m16s
gitea-memcached-7b44bc5f74-ql9fl   1/1     Running   0          3m16s
gitea-postgresql-0                 1/1     Running   0          3m17s
gitea-0                            0/1     Running   0          3m17s

MariaDB

Slightly quicker (with memcached disabled) at 2min50s

MySQL

Slower at almost 4mins

christian-kreuzberger-dtx commented 1 year ago

Just note that benchmarking a single run is not very representative, especially if you compare MariaDB, MySQL and PostgreSQL. There are many variables, especially on shared infrastructure.

But I agree in general that this adds more time to the initial startup time, and that because of resource limitations, it's currently not possible.

Thanks anyway for trying it out!

agardnerIT commented 1 year ago

I'm going to tentatively put this back on the table because Killercoda have just increased their disk sizes.

Will re-investigate.