#1775 f27 modular server release planning
Closed: Fixed 4 years ago Opened 4 years ago by kevin.

f27 modular server release was not fully ready for f27 beta. The Server WG decided to hold off since it wasn't ready and enact it's contingency plan. The council ( https://pagure.io/Fedora-Council/tickets/issue/141 ) determined that the modular server was very important to Fedora and our primary sponsor Red Hat and decided:

"Modularity is an important Fedora priority, and having it be a non-sidecar option is important to Red Hat as a stakeholder. Since Modularity allows us to decouple the Modular Server release from the GA date, we'd like to take advantage of that and ask the Server SIG and Modularity WG to come up with an alternate schedule landing as an official Edition about a month later."

Based on that we discussed things in today's (2017-09-15) meeting.

agreed: ask for formal ack from qa/releng/websites about this plan, write and approve a actual schedule with dates, make sure modular server passes release testing at any milestones. (+1:5, -1:0, +0:0)

So, the following actions need to take place:

  1. releng ( @mohanboddu @ausil ) needs to agree that this plan is possible for them

  2. qa ( @adamwill @pschindl @tflink @kparal ) need to agree that they can test modular server on this schedule in addition to the existing testing on f27.

  3. websites ( @robyduck ) needs to agree that they can make a modular server set of pages for a modular server beta and final release, in addition to the existing f27 work.

  4. @langdon will consult with stake holders and write up a schedule for next weeks meeting. This will have beta and final release dates for f27 modular server (possibly with rain dates). Note that later in november in north america is the thanksgiving holiday and fedora infrastructure also is planning a week with many outages in early december, so it would be good to release before those things.

  5. @langdon will write up/propose any release criteria that need to change to address testing modular server vs traditional server for qa folks.

  6. someone (?) needs to decide if we are shipping a legacy server along with f27 normal cycle or not. (IMHO, we should).

@mattdm @pfrields (or anyone else) add anything I forgot here.

Bodhi needs to be ready to update modules before the beta too, so there's some infrastructure readiness too.

If we are doing a seperate Modular server release then we need to think about mirroring. Its being tracked at https://pagure.io/modularity/issue/60 for which we still need to make a decision.

For F26 Boltron release, we didn't generate torrents. If torrents are needed then we need to look into that as well.

So far as qa is concerned, I mean, if we have bits to test at any time, we can test them. We run validation testing pretty much 365 days a year anyway.

The thing that concerns me here is we have a whole refined, documented process for doing releases as monoliths on a single schedule. We don't have a refined and documented process for doing...this. Each individual team probably thinks it can do what needs to be done, the thing we get from the release process is the 'glue' between the teams, so everyone knows how bits get generated and passed from releng through qa to the release process, and issues come up from qa to the developers and feed back into the releng cycle.

We have a process for doing two-week Atomic releases, but that's different because it relies entirely on automated testing; we can't really do that for a first release of modular Server, I think, we really need human eyes on it at some point.

@adamwill Yes, that's an excellent point. I'm going to make sure we have extra attention on that ... glue fabric. And will act as the glue where needed.

I have an opinion on point 6 — what to do with traditional Fedora Server.

Fedora as a server operating system continues to be quite popular. I don't have really solid numbers, but I'm comfortable with the rough assessment that 20-25% of users use Fedora in some server capacity. But, from feedback I gathered earlier this year, only a tiny majority are using Fedora Server as Server Edition per se. We never did get the momentum we hoped for for server roles, either in their new lightweight incarnation or the previous design. That's disappointing, but it's not surprising that not everything works out.

That's part of the reason to try this new Modular Server so quickly in the first place, schedule and everything aside — but, I think it also means that as long as we provide people continuity and a clear way to get some kind of Fedora running in a server context, we are largely okay.

Specifically, I think we should keep fedora-release-server, but should skip making the Server tree or install media. On the website at F27 GA, we should direct people to a document addressing three audiences:

People Waiting For Fedora Modular Server

"Coming Soon — this is gonna be awesome."

Ideally, we will have the beta for this available at general GA.

People Using Fedora as a Server, but not Fedora Server Edition necessarily

No problem! Not much changes here. Take a look at the "everything" netinstall, or else maybe Fedora Cloud Base. Or upgrade as usual.

Existing Fedora Server Users

You've got three options:
- Wait a little bit and migrate to new Fedora Modular Server when that's available
- dnf system-upgrade to Fedora Server 27
- Just stay on F26 until the end of that cycle, figure out what to do then (Possibly we'll have some kind of non-modular to modular upgrade path in the future?)

@mattdm without the Server variant people will not get the Server options. Defaults like XFS filesystem will not happen. I think for 27 and 28 we likely should keep doing the Server Variant, perhaps putting it in Alt with the Cloud Variant.

I totally agree with both @adamwill and @ausil. The specific POV of websites is:

  • We are able to set up a website for a different release cycle of Modular Server, but this means F27 Beta Modular Server should not be released before 3-4 weeks (but before F27GA)
  • I like the idea of having a legacy server image available for users who search for the F27 traditional server. alt.fp.o should be the place where this can live.

I would suggest to make something like that:

  • F27 Beta could have legacy server images on getfedora.org, but we will add a section on top that we are waiting for the new edition of Fedora Modular Server and explain that the traditional server image will be replaced by Modular server starting from F27GA.
  • Once we have F27 beta Modular Server ready we can put these images on top of the F27 prerelease download page
  • At F27 GA release date we will also replace the main server index page with new text and images, keep only F27 Beta Modular server on the download page (while WS and Atomic will switch to F27 GA) and move legacy server to alt.fp.o

We just need to figure out some deadlines to make a plan for the next month.

Personally, I don't think putting a traditional server beta out in any "real" capacity is a good idea because of the "beta should match GA". However, it can be "there" in the way @mattdm describes as available but without install media. I am pretty confident this is what the Server SIG believes too. However, on the rest of @robyduck's points, I agree.

I put together a modified version of the Release Schedule page to try to reflect some dates I think might work. However, I need feedback from @ausil, @mohanboddu, @adamwill , and @kparal. I didn't map the dates of modular-beta <-> traditional-ga only because I thought doing them separately might be a) easier b) less risky. However, as I think about it, is one "release" actually easier/safer for rel-eng? I am sure QA would appreciate the extra week. Please also keep in mind, "available" doesn't mean "promoted" so we may build modular-server-beta on the 17th but not announce it til the 24th.

Lastly, I don't think QA can afford to test both traditional and modular server. However, the testing for traditional workstation, cloud, etc may be sufficient to consider the traditional server build to be "good enough" as it isn't the primary deliverable. However, I would like QA to weigh in on this.

@langdon well, generic testing doesn't prove much about server beyond 'it probably installs and boots'. It doesn't go anywhere to proving whether Server meets its specific criteria to do with firewalls, cockpit, FreeIPA and postgres. The importance of these to actual users is a bit more of an open question, though.

The good news is that most of the existing Server testing is automated, so we get to know whether it's broken pretty much for free. Getting it fixed isn't free, but we would at least know whether it was broken pretty easily.

Note I've already spent a considerable amount of time and effort this cycle getting FreeIPA in particular even vaguely into shape.

Adding to the meeting for tomorrow. Also worth noting that the Server SIG voted to mark the non-modular Server Edition media as non-blocking.

It is important to get FESCo's sign-off, as it affects multiple groups.

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

4 years ago

AGREED: modular server release schedule is approved (+8,0,0) (nirik, 17:13:07)

Do we need to keep this open to track further items?

Metadata Update from @jforbes:
- Issue untagged with: meeting

4 years ago

retagging for review at the meeting. Beta has slipped and a rain date was not in the schedule for Beta. I believe we can add one and keep the final dates as is without having to push everything out.

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

4 years ago

I believe we can add one and keep the final dates as is without having to push everything out.

As I understand it, the platform module is not currently building; is this realistic? If it is achievable, I will buy beverages-of-choice for everyone. :)

I believe we can add one and keep the final dates as is without having to push everything out.

As I understand it, the platform module is not currently building; is this realistic? If it is achievable, I will buy beverages-of-choice for everyone. :)

Where are you getting that information? The Platform module was building successfully as recently as yesterday.

FESCo Meeting 2017-10-13

#agreed: Add a presumed one-week slip to be the Rain Date; slip Final if that isn't achieved. (+1:8, -1:0, +0:0)

Metadata Update from @maxamillion:
- Issue untagged with: meeting

4 years ago

Metadata Update from @sgallagh:
- Issue close_status updated to: Fixed

4 years ago

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

4 years ago

This looks like it was accidentally reopened.

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

4 years ago

Login to comment on this ticket.