#777 Improved text for default services page
Closed: accepted 10 months ago Opened a year ago by sgallagh.

Guideline page needing clarification:

https://fedoraproject.org/wiki/Packaging:DefaultServices

Explanation

In a recent FESCo ticket FESCo decided to clarify our stance on hardware-specific defaults. We would like the FPC to update the DefaultServices guidelines with these new goals in mind (copied below for convenience):

  • Services that meet all of the other requirements for starting by default are permitted to be enabled in systemd presets.
  • If certain hardware can be used without configuration, services which provide this support for this should be enabled by default.
  • Services that are only useful on a subset of hardware must exit gracefully and without marking the service as "failed" (from systemd's perspective) if that hardware is not present. This may be accomplished through systemd's conditionals, by having the service itself (or a wrapper script around it) exit with a zero return code, or similar functionality.
  • If there is value in the service optionally failing (such as if hardware that is expected to be present disappears or stops functioning), this may be made available using one or more of the following methods:

    • As an opt-in mechanism involving a userspace tool with proper documentation
    • The service may store state on the disk (in an appropriate location in /var) to use as a baseline for detecting the failure.

Metadata Update from @tibbs:
- Issue tagged with: meeting

a year ago

I'm kind of buried this week but if I can get a few minutes today I will try to whip something up.

Metadata Update from @tibbs:
- Issue tagged with: hasdraft

a year ago

Basic draft at https://fedoraproject.org/wiki/Tibbs:DefaultServices

I restructured most of the document to avoid constructs like "you must do A; you may do B but only if you do C; you must not do D and must do E". It just got too confusing to follow.

Now it defines a service and then says you can enable only if you meet a list of criteria. Then it talks about some cases where we want things to be enabled (so SHOULD instead of MAY).

And then that weird section about value in optionally failing comes along and contradicts all of the other rules and confuses things. I don't know what to do with that so I just stick it in mostly verbatim. I hope it isn't too confusing. I don't understand the point of the requirement at all and it doesn't seem to be related to default services so I don't really know how to rewrite it to have it make more sense.

The draft is good. You are right that the para about optionally failing is a non-sequitor for the general rules, but it still seems to be the best place to put it. It only applies to hardware, because hardware removal or failure is something that can happen without admin intent (it wouldn't make much sense to configure a normal daemon to fail at startup). We added that text because there are some maintainers who worry about the case where hardware is configured and then stops working, silently degrading the functioning of the machine. This gives them an option and general rules how to implement a check for removed hardware.

XXX Note that this allows services to start by default as long as they simply exit without error until they have been configured

Yeah, there is a small risk. We certainly don't want to enable all services by default and have them exit silently if they don't find config. But I'll trust our maintainers not do jump through that loophole. So I'd just leave the text here as is too.

From https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2018-07-19/fpc.2018-07-19-16.00.txt

  • x777 Improved text for default services page (geppetto, 16:19:40)
  • ACTION: Improved text for default services page (+1:7, 0:0, -1:0)
    (geppetto, 16:55:49)

Metadata Update from @james:
- Issue untagged with: meeting
- Issue tagged with: writeup

a year ago

I wrote this up during the meeting.

Announcement text:
The packaging guidelines for enabling services by default were significantly revised to emphasize that services starting by default should fail only in exceptional conditions, and to provide additional guidance for services related to hardware enablement.

Metadata Update from @tibbs:
- Issue untagged with: hasdraft, writeup
- Issue assigned to tibbs
- Issue tagged with: announce

a year ago

Metadata Update from @tibbs:
- Issue untagged with: announce
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

a year ago

Can we reopen this please? I just realized today that this rewrite lost an important section: "How to enable a service by default"

In particular, this included a requirement that a request to enable it comes through a Bugzilla template that prompts the user to answer questions about suitability for enabling by default.

We should be able to do this with less overhead now by simply opening a PR against https://src.fedoraproject.org/rpms/fedora-release. I wonder if pagure has the possibility to create templates for issues like github does.

We should be able to do this with less overhead now by simply opening a PR against https://src.fedoraproject.org/rpms/fedora-release. I wonder if pagure has the possibility to create templates for issues like github does.

I think we'd need a template for the PR description, because I would still want those key questions answered before we merged it. But the original process expressly wasn't about sending a patch because we can't assume that people understand how presets work or which file they should be added to. The idea was that they would describe the situation to us and we would implement it in the appropriate places.

Now you're explicitly asking for more work for yourself ;) A PR is better because it avoids questions like "what is the name of the service" and so on. The template can say to file an issue if you don't know what the PR should look like, but let's just encourage people to file PRs which is quicker and probably easier for everybody involved including the submitters.

Now you're explicitly asking for more work for yourself ;) A PR is better because it avoids questions like "what is the name of the service" and so on. The template can say to file an issue if you don't know what the PR should look like, but let's just encourage people to file PRs which is quicker and probably easier for everybody involved including the submitters.

Sure, but at the minimum we need to have clear guidelines for the repo maintainer to figure out if it's acceptable to merge or they should escalate it to FESCo/WG for a decision. Also all PRs should fail if they don't include a link to where that validity was established. (In the older version, it was the request BZ).

Metadata Update from @churchyard:
- Issue status updated to: Open (was: Closed)

10 months ago

Metadata Update from @tibbs:
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)

10 months ago

Login to comment on this ticket.

Metadata