#412 Please change the packaging guidelines to include packaging policy regarding systemd timer units
Closed: Fixed None Opened 5 years ago by johannbg.

Proposed policy

All packages with timed execution which already depend on systemd (for example because they contain systemd units) MUST use timer units instead of cron jobs, with no dependency or requirements on a crontab.

Packages which do not already depend or require systemd MUST NOT use timer units but instead depend and have requirement on crontabs, to avoid introducing unnecessary new dependencies on systemd directly.


Please note that this is part of F21 accepted system-wide change https://fedorahosted.org/fesco/ticket/1244, and therefore a policy should be in place before the F21 release -- ideally, I think, by the July branch from Rawhide. (I suppose the policy should at least initially clarify that it applies to F21 on, and that timer units shouldn't be introduced into older releases; that clarification could be removed when those releases retire.)

For the record, I am in favor of the policy as proposed, but would also be okay with a less restrictive "SHOULD NOT" for the second part, or "MUST NOT (without an [FPC|FESCo] exception)".

This proposal is submitted as is with must not

Or "MUST NOT (without an [FPC|FESCo] exception)

I'm okay with what's written. We also need guidelines for what a timer unit should look like. If I understand what they are, it probably goes in this section:

https://fedoraproject.org/wiki/Packaging:Systemd#Activation

We can't really pass this portion of the guideline without also adding something that describes what we want.

Replying to [comment:5 toshio]:

I'm okay with what's written. We also need guidelines for what a timer unit should look like.

I'm not going to see how you are going to achieve that as in making the timer unit generic enough( + those documentation dont cover all the 14 types of systemd units we have thus far ) that because you as an administrator would never create a local timer unit but only ever in rare cases overwrite the provided one from my pov.

I assume the cron like behaviour is what you are expecting just like people that expect systemd to be sysv when in fact it is a entirely a new concept and new technology with limited backwards compatibility to the "past"

Here you have an cron like a.k.a "traditional" hourly timer units you can build whatever guidelines requirements that satisfy you around it.

ackme-job.timer

[Unit]
Description=Ackme Sample Timer Trigger

Documentation=man:ackmed(1)

[Timer]

OnCalendar=hourly

[Install]

WantedBy=timers.target

ackme-job.service

[Unit]

Description=Daily Ackme Sample Job

Documentation=man:ackmed(1)

[Service]

User=ackme

ExecStart=/usr/bin/acme-job

And you package this the same way as you do with various other systemd units but in reality you need to tailor each timer unit just like is being done with migration from traditional initscript to type service systemd units so a generic example is not really useful or helpful...

Looks good. Now if someone can write a draft around that it would make this go quicker....

I'm against adding timer unit example to FPG since it can be seriously misleading and might even give the false notion that cron script in package which do not already depend on systemd should get migrated.

So those that are insisting on including this example feel free to write this draft.

info Timer activation with some revisions passed: (+1:5, 0:0, -1:0)

The revision was that the MUSTs be changed to SHOULDs. Discussion here:
http://meetbot.fedoraproject.org/teams/fpc/fpc.2014-04-03-16.02.log.html#l-262

The discussion was a little short because of lack of time in the meeting and needing to get to other tickets that also affected Fedora Changes. FPC could consider changing the SHOULDs back into MUSTs with some explanation.

Johannbg re-raised this at FESCo this week and notting will hopefully be coming to an FPC meeting to explain the rationale for having MUSTs in the guidelines.

Since I will not be present for the next few weeks, I am pre-registering my vote as +1 to changing the SHOULDs to MUSTs.

Did anything ever happen here? From my poor memory and the above discussion we were trying to decide nothing more than the should/must issue. If this is still relevant we should really discuss it in a meeting.

This got decided with bullshit decision on http://meetbot.fedoraproject.org/teams/fpc/fpc.2014-04-17-16.00.log.html after Notting tried to reason with you ( and by you I mean the FPC at that time ) and I dropped the feature along with any other systemd conversation effort as a result of that crap.

No need for you ( as in the FPC ) to go through that again until those individuals that made up the FPC at that time along with Matt file a new feature proposal that adhere to your expectation and conclude the conversion for whatever you consider relevant to be migrated.

My interpretation of that log is quite different (and positive), I see a vote on
https://fedoraproject.org/wiki/User:Notting/timer

which passed
16:49:46 <geppetto> #info systemd timer guidlines wording change to use MUST (+1:6, 0:0, -1:0)

Am I missing something?

Yes this boiled down to components that ship cron jobs but dont already depend on systemd unit's must not be allowed to be migrated to timer units.

I disagree with your interpretation of the decision. In fact, the wording of the proposed guideline was changed to help avoid that potential confusion.

?

That wording says

Components that already depends on systemd must be migrated
( for the most part the above makes sense )

And

Components cannot depend on both cron and systemd.

That proposal never says...

You cannot migrated a component that contains a cron job but does not already depend on systemd

If it made sense and the intent was to migrate every cron job to native systemd units and have those components depend on systemd as an result of that I would written a proposal that would have done just that as opposed to fix cron dependency in 50 components then proceed to go to migrated/convert the other ca 50 components.

Yes, I know you wanted to migrate everything to systemd units. That is not what this proposal was about. (I hope we agree on that part).

You argued the proposal prevented migration to systemd units, which is what I disagreed with.

Replying to [comment:18 rdieter]:

Yes, I know you wanted to migrate everything to systemd units. That is not what this proposal was about. (I hope we agree on that part).

No I did not want to migrate every cron job to systemd timer units since it makes absolutely no sense

You argued the proposal prevented migration to systemd units, which is what I disagreed with.

Yes because it makes absolutely no sense to migrate cron jobs that reside in components that do not already depend on systemd, to systemd timers and have those component having to depend on systemd as an result of that.

If we put aside the lack of practical purpose of migrating cron jobs for components that do not already depend on systemd then you must understand that we need to be able to trust there exist proper and correct dependency in components so we can rely on packaging tools to give us accurate results and thus be able to determine the actual scope, affected components and thus the outcome of changes we make when we either introduce or remove an component.

One of FESCo/FPC fundamental responsibility and the purpose of the guideline is to ensure just that and they have failed big time ensuring that's taking place.

You have absolutely no idea how many components in the distribution exist that just magically expect certain core/baseOS component to exist there indefinitely where the maintainers of those components have simply decided not to declare that dependency on the spec file for their component and then fail miraculous ( and that failure often goes unnoticed ) as a result of that when you remove a component from the core/baseOS

I literally spend hours upon hours chasing down non existing dependency in components to properly correctly map the scope of some of the systemd changes as an result of that, something I should have been able to do in a jiffy ( not only me but the feature wrangler and fesco as well to confirm the scope of said changes).

We discussed this again at this weeks meeting (http://meetbot.fedoraproject.org
/fedora-meeting-1/2015-01-08/fpc.2015-01-08-17.01.txt), summary is:

  • 412 Please change the packaging guidelines to include packaging


    (geppetto, 18:19:10)
  • LINK: https://fedorahosted.org/fpc/ticket/412 (geppetto, 18:19:10)
  • ACTION: follow vote from 9 months ago, writeup policy in description
    (geppetto, 18:26:35)

Announcement text:

Information on when when timer activation must and must not be used was added to the Systemd guidelines: https://fedoraproject.org/wiki/Packaging:Systemd#Timer_activation

Metadata Update from @rdieter:
- Issue assigned to tibbs

2 years ago

Login to comment on this ticket.

Metadata