Hi folks,
We decided to add cron to compress some merged logs. So I realize that we didn't have any Ansible role to do this. Currently we manage cron tasks separately in the component's role, and IMO it will be difficult to find/make modifications when needed.
Do you think it's beneficial to create new one ? Or perhaps someone has clever ideas :) ?
+1/-1 ??
seddik (saibug)
On Fri, May 26, 2023 at 04:28:56PM +0200, seddik alaoui ismaili wrote:
Hi folks,
We decided to add cron to compress some merged logs. So I realize that we didn't have any Ansible role to do this. Currently we manage cron tasks separately in the component's role, and IMO it will be difficult to find/make modifications when needed.
Do you think it's beneficial to create new one ? Or perhaps someone has clever ideas :) ?
+1/-1 ??
I'm not sure cron is big enough to make a role worthwhile.
You mean make a role that takes file/template name, when to run and puts it in /etc/cron.d/ ?
We do have the ansible 'cron' module, which can do /etc/cron.d/ files as well, but of course still needs copying the template/file script first before it can be scheduled.
So, I could be convinced, but I don't think it's worth it off hand...
Happy to hear other/more thoughts on it tho, and thanks for bringing up the idea. It's nice when we can consolidate things into less duplication. :)
kevin
Le ven. 26 mai 2023 à 20:10, Kevin Fenzi kevin@scrye.com a écrit :
On Fri, May 26, 2023 at 04:28:56PM +0200, seddik alaoui ismaili wrote:
Hi folks,
We decided to add cron to compress some merged logs. So I realize that we didn't have any Ansible role to do this. Currently we manage cron tasks separately in the component's role, and
IMO
it will be difficult to find/make modifications when needed.
Do you think it's beneficial to create new one ? Or perhaps someone has clever ideas :) ?
+1/-1 ??
I'm not sure cron is big enough to make a role worthwhile.
You mean make a role that takes file/template name, when to run and puts it in /etc/cron.d/ ? Yes absolutely !
We do have the ansible 'cron' module, which can do /etc/cron.d/ files as well, but of course still needs copying the template/file script first before it can be scheduled.
So, I could be convinced, but I don't think it's worth it off hand...
The idea is to minimize the task of ansible roles, and avoid having the same tasks everywhere (copy script and schedule the job). I admit that it's not going to be easy but it can be done . Otherwise we will have only one role (cron) , and an overloading variable under group_vars.
Happy to hear other/more thoughts on it tho, and thanks for bringing up the idea. It's nice when we can consolidate things into less duplication. :)
kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I think that cron jobs should be within the role that they belong to, ie. Postfix cron jobs would be in the Postfix role. In my opinion this keeps everything organized and consistent. If we have small one offs that need special care we can take care of it as it comes up. Having a role for just cron to me would add more complications when changes are made and when jobs/roles need debugging.
On Fri, May 26, 2023, 7:10 PM seddik alaoui ismaili < seddikalaouiismaili@gmail.com> wrote:
Le ven. 26 mai 2023 à 20:10, Kevin Fenzi kevin@scrye.com a écrit :
On Fri, May 26, 2023 at 04:28:56PM +0200, seddik alaoui ismaili wrote:
Hi folks,
We decided to add cron to compress some merged logs. So I realize that
we
didn't have any Ansible role to do this. Currently we manage cron tasks separately in the component's role, and
IMO
it will be difficult to find/make modifications when needed.
Do you think it's beneficial to create new one ? Or perhaps someone has clever ideas :) ?
+1/-1 ??
I'm not sure cron is big enough to make a role worthwhile.
You mean make a role that takes file/template name, when to run and puts it in /etc/cron.d/ ? Yes absolutely !
We do have the ansible 'cron' module, which can do /etc/cron.d/ files as well, but of course still needs copying the template/file script first before it can be scheduled.
So, I could be convinced, but I don't think it's worth it off hand...
The idea is to minimize the task of ansible roles, and avoid havingthe same tasks everywhere (copy script and schedule the job). I admit that it's not going to be easy but it can be done . Otherwise we will have only one role (cron) , and an overloading variable under group_vars.
Happy to hear other/more thoughts on it tho, and thanks for bringing up the idea. It's nice when we can consolidate things into less duplication. :)
kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I agree with that, it's much easier to find the corresponding cron job if it's in the role it belongs to.
Michal
On 27. 05. 23 14:51, Andrew Heath wrote:
I think that cron jobs should be within the role that they belong to, ie. Postfix cron jobs would be in the Postfix role. In my opinion this keeps everything organized and consistent. If we have small one offs that need special care we can take care of it as it comes up. Having a role for just cron to me would add more complications when changes are made and when jobs/roles need debugging.
On Fri, May 26, 2023, 7:10 PM seddik alaoui ismaili seddikalaouiismaili@gmail.com wrote:
Le ven. 26 mai 2023 à 20:10, Kevin Fenzi <kevin@scrye.com> a écrit : On Fri, May 26, 2023 at 04:28:56PM +0200, seddik alaoui ismaili wrote: > Hi folks, > > We decided to add cron to compress some merged logs. So I realize that we > didn't have any Ansible role to do this. > Currently we manage cron tasks separately in the component's role, and IMO > it will be difficult to find/make modifications when needed. > > Do you think it's beneficial to create new one ? Or perhaps someone has > clever ideas :) ? > > +1/-1 ?? I'm not sure cron is big enough to make a role worthwhile. You mean make a role that takes file/template name, when to run and puts it in /etc/cron.d/ ? Yes absolutely ! We do have the ansible 'cron' module, which can do /etc/cron.d/ files as well, but of course still needs copying the template/file script first before it can be scheduled. So, I could be convinced, but I don't think it's worth it off hand... The idea is to minimize the task of ansible roles, and avoid having the same tasks everywhere (copy script and schedule the job). I admit that it's not going to be easy but it can be done . Otherwise we will have only one role (cron) , and an overloading variable under group_vars. Happy to hear other/more thoughts on it tho, and thanks for bringing up the idea. It's nice when we can consolidate things into less duplication. :) kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure mailing list --infrastructure@lists.fedoraproject.org To unsubscribe send an email toinfrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
I think this new method is also faster, in case if you want to modify a cron for such machines, for example it will be under* group_vars/GRPOUPE_NAME/cron.yaml*, and not in *roles/role_name/tasks/main.yaml* and then search for the line that contains cron module!!! .
The approach is a little different here, but i understand the fact that you want to keep the existing method. I'm also convinced that it's not easy to migrate, but still possible .
Seddik
Le lun. 29 mai 2023 à 10:19, Michal Konecny mkonecny@redhat.com a écrit :
I agree with that, it's much easier to find the corresponding cron job if it's in the role it belongs to.
Michal
On 27. 05. 23 14:51, Andrew Heath wrote:
I think that cron jobs should be within the role that they belong to, ie. Postfix cron jobs would be in the Postfix role. In my opinion this keeps everything organized and consistent. If we have small one offs that need special care we can take care of it as it comes up. Having a role for just cron to me would add more complications when changes are made and when jobs/roles need debugging.
On Fri, May 26, 2023, 7:10 PM seddik alaoui ismaili < seddikalaouiismaili@gmail.com> wrote:
Le ven. 26 mai 2023 à 20:10, Kevin Fenzi kevin@scrye.com a écrit :
On Fri, May 26, 2023 at 04:28:56PM +0200, seddik alaoui ismaili wrote:
Hi folks,
We decided to add cron to compress some merged logs. So I realize that
we
didn't have any Ansible role to do this. Currently we manage cron tasks separately in the component's role,
and IMO
it will be difficult to find/make modifications when needed.
Do you think it's beneficial to create new one ? Or perhaps someone has clever ideas :) ?
+1/-1 ??
I'm not sure cron is big enough to make a role worthwhile.
You mean make a role that takes file/template name, when to run and puts it in /etc/cron.d/ ? Yes absolutely !
We do have the ansible 'cron' module, which can do /etc/cron.d/ files as well, but of course still needs copying the template/file script first before it can be scheduled.
So, I could be convinced, but I don't think it's worth it off hand...
The idea is to minimize the task of ansible roles, and avoid havingthe same tasks everywhere (copy script and schedule the job). I admit that it's not going to be easy but it can be done . Otherwise we will have only one role (cron) , and an overloading variable under group_vars.
Happy to hear other/more thoughts on it tho, and thanks for bringing up the idea. It's nice when we can consolidate things into less duplication. :)
kevin _______________________________________________ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
infrastructure@lists.fedoraproject.org
-
Andrew Heath -
Kevin Fenzi -
Michal Konecny -
seddik alaoui ismaili