How to remove previous jobs?

[Turab]

Hi,

Using Caprover overrides to register jobs and it works. However, when I change the name of the job an save; I get two jobs. Means the old job still stays there. How can I remove the jobs?

Btw, I have my instance complaining that there isn't a config file; which there really isn't. I am running Chadburn from single-click app in Caprover.

[maietta]

This is the behavior of docker service labels itself. Every rule that applies to docker service labels will apply in Chadburn.

So yes, this is expected behavior, technically speaking. From a user's perspective, it seems broken.

To deal with this until a total rewrite of Chadburn has arrived, you'll need to overwrite any existing labels with a value of false.

[Turab]

Oddly, when I renamed the job, Chadburn console actually said that the previous job was deregistered. Well that was not the case. Before seeing this message of yours, I also tried disabling the job altogether by setting: chadburn.enabled: "false". With that, both jobs were reported to be deregistered in Chadburn console. Today I re-enabled the job, and both jobs got registered again.

So this workaround also doesn't work.

[maietta]

Okay, thanks for the update. I'll look into this as a possible bug but I will not be able to get to this until later this weekend, earliest tomorrow. I'll follow up here.

[Turab]

Reading your previous suggestion, it came to me that I could have misunderstood what you said. So to clarify, I will ask this; is it possible for one container to enable a job and disable the other?

Actually I don't think so, because "chadburn.enabled" directive is job-name-agnostic and looks pretty global for the container. If I misunderstood and it is possible to enable one job and disable the other at the same time for the same container, then I will kindly ask you to instruct me to do so. Otherwise your latest verdict applies and I will be waiting for a possible bug fix.

[maietta]

No problem. Yes, you can disable and enable another job, keeping in mind it's not as simple as setting the chadburn.enable flag to true or false when you have multiple job commands and schedules applied. You have to remove the ones you don't want because of the chadburn.enable flag will apply to all labels beginning with chadburn.

I made a mistake previously when I said "service labels". Technically, the labels are applied to the containers, not services.

I haven't found exactly how to remove labels on containers directly, without re-deploying a service. I use Caprover to update the labels and Portainer to inspect, but also can inspect at the command line. I'll need to go through and find out just exactly how to modify labels on running containers via command line and document that.

For example, say I have 2 different jobs and I want to disable the rotate-other-puzzles task:

      chadburn.enabled: "true"
      chadburn.job-exec.rotate-puzzles.command: "php81 /var/www/html/index.php /api/rotate/regular"
      chadburn.job-exec.rotate-puzzles.schedule: "@every 1m"
      chadburn.job-exec.rotate-other-puzzles.command: "php81 /var/www/html/index.php /api/rotate/other"
      chadburn.job-exec.rotate-other-puzzles.schedule: "@every 10s"

I would be forced to alter the chadburn.job-exec.rotate-other-puzzles.command and chadburn.job-exec.rotate-other-puzzles.schedule to be something else, like changing "php81 /var/www/html/index.php /api/rotate/other" to "time" and adjust schedule to be few and far between, just so I can effectively disable this rotate-other-puzzles task.

It is definitely not a clean solution and I really don't like this. That's why in Chadburn 2.x, I'm going to be spending time addressing this.

[Turab]

Ok, then our previous track is prevailing, waiting for when are you ready. Because that's what we talked before anyway. I removed the jobs from the labels and Chadburn recognized and output "deregistered" for that job on its console; but actually it didn't. As soon as any jobs from that same container are registered; the old, now-not-existing (i.e. removed from labels) jobs are also registered.

Since I am using Caprover service override, I will give the re-produce steps accordingly;

• Do a service override and add a Chadburn job to the app
• Rename the job and save the container.

• Now you have two jobs, although you just renamed the existing one and although Chadburn reported the old job was deregistered.

Then;

• Completely disable Chadburn on this container with chadburn.enabled directive
• Both jobs get deregistered
• Enable the directive again, with only one job present in the service override template

• You have two jobs again; with the old and new names.

By the way, thanks for the good work and also thanks for your time here.

[maietta]

Glad to see you are using Caprover! Woohoo!!! That makes my day. I'm now contributing to that project as well.

I edited my previous response, please take a look. I suspect we do have a problem here with multiple unique tasks per service and needing to target one for removal, etc.

[Turab]

Great to hear you are active on both projects.

In fact I didn't have two different jobs in one app. I just wanted to rename the one-and-only, and here we are 🙂

Now per your latest suggestion, I now put the old name as another job to run yearly. Not the neatest solution, but at least it works, and hopefully it won't run that job again before the next version of Chadburn comes out 😅

[maietta]

So I think I'm following the problem, thanks to the description of how to reproduce. The fact that you renamed the app, means you renamed the service. Now I am wondering if renaming services cause orphaned labels somehow. I need to better understand what's going on through hands-on observations.

Your use of both Chadburn and Caprover together really is a bonus for this discussion since I am working on and contributing to both. And you're welcome. I really wish I was living on sponsorships and donations because then I can devote my time to these projects to get them better for everyone. This is something I'm working to accomplish over the next few months.

[Turab]

No I didn't rename the app; I renamed the job, in the service override template.

[maietta]

Ah! Got it. Okay, either way, it's orphaned. Renaming the job/task means the label still persists on the containers themselves. You can use something like Portainer (available as a one-click-app) to let you inspect your docker swarm, services, containers, etc or you can run " docker inspect eff146f0bf53"

You can get the unique container name from docker ps | grep your-app-name

In this way, you can verify the labels currently applied to your running container.

[Turab]

By that command, and by Portainer, I can see only one label attached to this app, which is actually what I gave as the new job name. The old name of the job doesn't eixst as a label anywhere.