Fedora-Modular validation events disabled
by Adam Williamson
Hi, folks.
So over the last couple of days, the Server SIG and the Council have
decided not to go ahead with a Fedora Modular Server 27 release.
Accordingly, I've disabled the creation of the special Modular
validation events (though I've left all the code that supports them in
place just in case we turn out to need it in future). 20171123.n.1 will
remain as the 'current' Modular validation event, but it is my
understanding that no further validation testing work is required, and
we can focus on Fedora 28 so far as the validation process goes.
My current understanding is that for Fedora 28 we plan to roll modular
deliverables into the main compose process, so we will once again have
only one compose series to validate. However, I don't know what the
timeline for this to happen is at present.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 3 months
Server SIG Weekly Meeting Minutes (2017-11-28)
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
================================================================
#fedora-meeting-1: Fedora Server SIG Weekly Meeting (2017-11-28)
================================================================
Meeting started by sgallagh at 21:00:13 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-1/2017-11-28/serversig...
.
Meeting summary
- ---------------
* Roll Call (sgallagh, 21:00:13)
* Agenda (sgallagh, 21:03:44)
* Agenda Item: To GA or not GA, that is the question. (sgallagh,
21:03:44)
* To GA or not GA, that is the question. (sgallagh, 21:06:36)
* LINK: https://pagure.io/Fedora-Council/tickets/issue/149
(sgallagh, 21:07:17)
* AGREED: Server SIG does not want to ship a formal GA of Fedora 27
Modular Server (sgallagh, 21:32:39)
* LINK:
https://kojipkgs.fedoraproject.org/compose/Fedora-Modular-27-20171128.n.1/
is the most recent for e.g. (adamw, 21:37:06)
* AGREED: The Server WG recommendation is not to bother with a Boltron
2 release, but this is ultimately up to the Council and the
Modularity WG to decide. (sgallagh, 21:49:58)
* LINK:
https://pagure.io/Fedora-Council/tickets/issue/149#comment-481872
(adamw, 21:52:59)
* AGREED: Since the GA RC compose passed the Server tests, Server WG
would like to just release the Server Edition content from that
compose as the official Fedora 27 Server Edition (sgallagh,
22:02:35)
Meeting ended at 22:07:03 UTC.
Action Items
- ------------
Action Items, by person
- -----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
- ---------------------------
* sgallagh (99)
* adamw (61)
* langdon (35)
* smooge (28)
* nirik (26)
* zodbot (18)
* asamalik (8)
* mattdm (6)
* mjwolf (4)
* dperpeet (3)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
-----BEGIN PGP SIGNATURE-----
Version: Mailvelope v2.0.0
Comment: https://www.mailvelope.com
wkYEAREIABAFAlod3isJEHolVWI2uqOjAADhCACgkvFOYpjr8wT+q6sUOMdS
ddbjTPcAn0a+hZIIwBzwFrF+BAZkaDAbc7rI
=u9W4
-----END PGP SIGNATURE-----
5 years, 3 months
Re: Important: tomorrow's meeting will be a special session Modular Server
by Stephen Gallagher
On Tue, Nov 28, 2017 at 8:26 AM Matthew Miller <mattdm(a)fedoraproject.org>
wrote:
> We're going to delay Stef's presentation on CI until next week, because
> this is a fairly urgent decision with a lot of consequences. See
> discussion in ticket at
> <https://pagure.io/Fedora-Council/tickets/issue/149>.
>
> Ideally, I'd like to get that all hashed out in the meeting tomorrow.
> An hour isn't a lot of time if discussion goes every which way, so I'll
> spend a little bit of time today thinking about how to break up the
> questions so we can be efficient with our "live" time.
>
I'm also putting this as the sole item on the agenda for today's Server SIG
meeting, so it would probably be a good idea if folks attended that if at
all possible (I know it's late in Europe; it's at 1600 EST)
5 years, 3 months
Fedora 27 Modular Server release validation
by Adam Williamson
Hi folks!
So it's been an open question exactly how we would do release
validation for the Modular Server release. For Beta, we wound up trying
to co-ordinate it via mailing list and IRC; I thought doing it this way
would be sufficient and save time trying to set up a parallel stream of
wiki validation events.
However, I don't think it really turned out that well; we didn't have a
great overview of test coverage at the Beta go/no-go meeting, and just
wound up shipping it more or less on a handwave. And people keep asking
about where they can find and report results for the Modular Server
composes.
So, I went ahead and spent the last couple of days enhancing all the
release validation bits to handle having release validation events for
Modular composes, in a way which hopefully won't screw anything up.
The way it *should* work, if I got it all right, is this:
The fedmsg consumer which automatically creates release validation
events will now also create events for Fedora-Modular 27 composes,
following the exact same rules it follows for creating regular
validation events. I have also created an initial Modular validation
event, for the Beta-1.5 compose we signed off as the Modular Server
Beta. And I have set things up so there's a new set of 'Current'
redirect pages for the Modular events, with 'Current_Modular' in their
name:
https://fedoraproject.org/wiki/Test_Results:Current_Modular_Summary
https://fedoraproject.org/wiki/Test_Results:Current_Modular_Installation_...
https://fedoraproject.org/wiki/Test_Results:Current_Modular_Server_Test
https://fedoraproject.org/wiki/Test_Results:Current_Modular_Base_Test
At present those links will redirect you to the Beta 1.5 pages. You'll
notice the page names follow the same basic scheme as for non-modular
events, just with "Fedora Modular" replacing "Fedora". This similarly
applies to all the category names, so there is now a "Fedora Modular 27
Beta Test Results" category and so on.
You may note the contents of the Installation and Base results pages
are a bit different, effectively I've cut them down to the bits that
are relevant to a compose which is intended to deliver only Server
bits. This is achieved by using separate matrix template pages:
https://fedoraproject.org/wiki/Template:Base_modular_test_matrix
https://fedoraproject.org/wiki/Template:Installation_modular_test_matrix
I'm usually the only one who edits the matrix templates anyway, but
thought I'd note it just in case. Naturally, if you want to change the
result pages for modular events, you edit the modular template pages,
and vice versa. Server_modular_test_matrix exists but is just a
redirect to Server_test_matrix , as we don't want those tables to
differ at all. For Modular events, only Installation, Server and Base
pages are created; Desktop and Cloud are not needed or relevant.
The consumer should create a new event for a nightly compose as soon as
one appears that has significant package differences from the Beta 1.5
compose. Events for modular composes should be announced by email just
as non-modular events are; the text of the email is of course adjusted
slightly to distinguish between modular and non-modular events.
openQA results should get forwarded to the wiki just as they do for
non-modular composes (I have forwarded the results for Beta 1.5 to the
wiki to test the mechanism, for future composes/events it should happen
automatically).
All the relval sub-commands now support operating on modular
composes/events. So you can use relval to create modular events
(though, again, normally the fedmsg consumer will do this for us
automatically, no-one needs to do it manually), report results for
modular composes, run the image size checks on modular composes, and do
the user-stats and testcase-stats analysis for modular composes. For
each sub-command, a new argument `--modular` is available which tells
it to operate on a modular compose/event/set of events. For report-
results, you can run just `relval report-results --modular` to report
results for the current Modular validation event.
You can find testcase_stats for 27 Modular at
https://www.happyassassin.net/testcase_stats/27modular/ . This link
will be included in announcement emails for Modular validation events.
Updates are available for EPEL 7, Fedora 25, Fedora 26 and Fedora 27
containing the updated relval, python-wikitcms and fedfind packages.
I've just submitted these, so they should reach updates-testing
shortly. If you want to use relval to report results for modular
composes, you'll want to update to the new versions (fedfind 3.8.0,
python-wikitcms 2.2.0, relval 2.2.0).
Ultimately, for the Final phase of the Fedora 27 Modular Server
release, we should be able to do release validation just as we do for
regular releases.
For now I've implemented all of this with two assumptions: we're only
going to have this split 'regular / modular server' schedule for F27,
and the modular composes won't have any bits we care about besides
server bits. If either of those assumptions turns out to be wrong,
we'll have to revisit this again.
Please do drop me a line if you spot anything wrong/weird/broken-
looking in any of this modular handling. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 4 months
Proposal to CANCEL: 2017-11-20 blocker review meeting
by Adam Williamson
Hi folks! I'm proposing we cancel the blocker review meeting for
Monday, as there are no proposed Server Final blockers at present.
Please yell if you think we will need to run a meeting. However,
I'm on vacation on Monday, so if we do need to run a meeting,
someone else will have to lead. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 4 months
Proposal to CANCEL: 2017-11-13 blocker review meeting
by Adam Williamson
Hi folks! I'm proposing we cancel the blocker review meeting for
Monday, as there are no proposed Server Final blockers at present.
Please yell if you think we will need to run a meeting. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5 years, 4 months
Name of the next Fedora Server release
by Andrea Bolognani
Hi there!
According to Langdon this topic has not really been discussed
properly yet, so I'd like to bring it up now. I know it's kinda late,
but hopefully not quite *too* late :)
Long story short, I'm not sure releasing the output of the Modularity
effort as Fedora Server, which seems to be the current plan, is
necessarily the best idea.
The Fedora Server moniker has been used for a pretty long while now,
and in that time users have come to expect certain things from it.
Modularity causes some of those expectations not to be met in its
current form. Quick example:
# dnf install screen
No match for argument: screen
Error: Unable to find a match
For users who have not been paying close attention to recent Fedora
development, and are just downloading the Fedora Server 27 .iso
expecting it to be "Fedora Server 26, but with newer software",
installing the new OS and hitting something like that right away
could lead to some frustration. Looking up more information about
Modularity would certainly explain things in a satisfactory manner,
but the importance of first impressions should not be underestimated.
At the same time, calling the output of the Modularity effort Fedora
Server doesn't do much to highlight just how much of a reimagining
of the traditional server OS it is.
Based on the above, my proposal is to drop the Fedora Server moniker
entirely and release as Fedora Modular Server instead.
The advantage of doing so is that using a different name signals a
clear break from previous Fedora Server releases: it's a new product,
one that you shouldn't expect to be a drop-in replacement. It's also
a name that you haven't heard before, which might pique your interest
even if you haven't been using Fedora up until now. I think it would
have a positive outcome on the way this release is received.
Moreover, the repositories themselves are already named like that!
So it would be just[1] a matter of doubling down on that name and
making sure it's being used consistently everywhere.
Looking forward to your feedback :)
[1] Note that I have no idea how much actual work that would entail
--
Andrea Bolognani / Red Hat / Virtualization
5 years, 4 months