lin
``` registry=> select count(1) from execution; count ------- 50540 (1 row) ```
cc @chlins ### (select * from execution where status='Running') Result ``` registry=> select * from execution where status='Running'; id | vendor_type | vendor_id | status | status_message | trigger |...
> So do you still have the running retention jobs in your harbor? Sure ### kubectl logs khub-harbor-jobservice-58cd47888f-g9s84 -n harbor | grep ERROR ```text 2022-08-02T15:59:31Z [ERROR] [/jobservice/runner/redis.go:93]: Track job f08911e784c947b756c81111:...
@chlins hey, i see the error log, but why error, i have no idea. ptal!! tks
BTW, i see harbor wiki : https://github.com/goharbor/harbor/wiki/Harbor-FAQs#job-service, because the job so many, which i only flush harbor redis(job-service). and then restart harbor all compoent.
@chlins I have already implemented it according to the wiki(https://github.com/goharbor/harbor/wiki/Harbor-FAQs#job-service ), because harbor has a lot of db, I only need to delete the db related to job-service. According to...
@chlins > Could you share the current size of your data(such as repo and artifacts numbers) and the frequency of previous retention executions? Of course. we have 241 repo, and...
> In my opinion, retention job can help to reduce the artifacts numbers in the harbor which can help to maintain, but this feature should work with GC because retention...
>最近在研究分布式调度，分享一下自己的经验和想法。 在这里首先贴一下google的分布式调度的介绍[distributed-periodic-scheduling](https://landing.google.com/sre/sre-book/chapters/distributed-periodic-scheduling/), 我觉得应该自己去设计一个job系统，可以基于cron这些类库做成分布式的。 先说说前期的我们是怎么做的把? 版本一: 基于cron类库做一些改造，支持分布式的job调度。利用etcd的分布式锁对job抢占。 ,而job的执行的方式只支持执行shell的。整体架构就是用的etcd存储要跑的node节点， 然后需要执行的job的等一些主要的元数据，然后日志丢到mongodb去做。这是我们最初的 版本设计。 版本一遇到一些问题: * 没有对执行器抽象(例如只支持shell) * 不能选定节点调度(比如我有a,b,c节点进行抢占) * 多个节点跑job(如果想做成主备的job,由于一些job太快会导致每个节点都在跑) * 不支持节点自动调度(比如，我有三个节点，a,b,c，和作业j，a的机器资源(cpu,内存)，而job跑的需要更* * 大的资源，我需要把作业j首先放到a节点跑，然后a挂了，自动跑到b或者c跑，然后a起来了，自动跑到a上跑。而不在b和c。) * 日志有进行抽象，只是存储在mongodb。不可扩展。 * 不支持依赖job(比如有三个job，a,b,c，我需要执行的依赖先等c执行完在再执行a再执行b) 版本二进行了重新设计: * 架构分成 agent 和manager的设计。manager管理job，下发job 到agent(可以指定)，通信采用的grpc。manager用的etcd做的选举。agent也可以选举。之间成员变更状态同步用的gossip。...