server February 2014

server@lists.fedoraproject.org

42 participants
27 discussions

Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
by Adam Williamson 27 Feb '14

27 Feb '14

On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: > Installer is still a hot topic, but thats nothing we could resolve > during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? To give a bit of background and detail in QA's interest: First, to ensure everyone actually knows what we're talking about, we tend to talk about two major partitioning 'paths' in anaconda: 'guided' and 'custom'. 'custom' may also be referred to as 'manual'. In both newUI and oldUI, 'guided' is simply what you get if you don't pick custom partitioning, when you are given the opportunity to do so. In oldUI, you had the screen which gave you about five choices of different partitioning 'approaches' (reformat the entire disk(s), reformat only the Linux partitions, resize existing partitions to create free space, just install into free space, maybe one or two others I forgot). In newUI there's a different workflow after you pick target disks on the Installation Destination spoke which, broadly, accomplishes the same options in a rather different way. Broadly, QA is interested in doing something similar to what desktop wants to do, for slightly different reasons. Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. Later in the 'oldUI' days, the path to more complexity in the 'guided' path was opened up by a sort of hack. Some people did not want LVM (after it was made default waaaaay back in FC3 or something), and eventually this demand became so persistent that it was decided to stick a checkbox in the 'guided' partitioning path which let you get a plain ext(3/4) layout instead of an LVM layout. This was always a kind of ugly compromise, it wasn't intended to be a design decision. It was manageable, because a plain ext3/4 layout is a fairly simple thing that isn't likely to break much. This context was kind of lost in the newUI re-design, and the 'I don't want LVM' checkbox kind of got a promotion. It's not a very good UI, and the point of the newUI stuff was to make the UI better, so instead of this 'special' checkbox, newUI used a dropdown menu - and because we were all ra-ra for btrfs at the time and expecting it to be the default Real Soon Now, and we thought we should make it easy for people to test the thing that was soon going to be the default, it got btrfs added. So in F18 we had a dropdown with "LVM", "ext4" and "btrfs" choices (IIRC). With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. By F20 we'd really kind of lost track of the initial intent, so no-one (including QA) really worried much about adding LVM thinp to the drop-down - it's a drop-down! it's for choices! - and now, we've got *four* major choices on the path that was originally supposed to be very dependable and choice-free and testable and maintainable, and of course we wound up shipping one of them entirely broken out of the box. QA and anaconda have already discussed this and, I think, we came to a tentative agreement that we could look at at least reducing the level of choice in 'non-custom' partitioning, and remembering the original intent we had (which I think both QA and anaconda teams quite like). It may be difficult to entirely drop the selection, but it seems at least reasonable to go back to only having one 'plain partition' choice and one 'LVM' choice (whether it's 'regular' LVM or thinp LVM), and relegating other choices to the 'custom' path. QA's angle on this is that it's really extremely difficult to develop a plausible set of storage release criteria and validation tests with the current situation. If we map out all the possible paths through the 'non-custom' path it still comes out to something like 80, given the current level of choice, and it's pretty impractical to test 80 different routes at every TC/RC build. Or even at every milestone. So if we don't change the design, QA is effectively forced to test only a reduced subset of the 'non-custom' path choices, whether we *plan* to do that or we pretend we're going to test them all but, inevitably, don't. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others. Anyhow, that's kind of where we left off back in December or January, and we probably really ought to get around to looking at this again - and, as I said, incorporating the perspectives of the different Product WGs and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

9 13

Fedora Board Working Group PRD approval
by Josh Boyer 26 Feb '14

26 Feb '14

The Board has reviewed the PRDs for the Cloud, Server, and Workstation products and approves. While there are some reservations in certain areas, the overall goals of each product seem to be well thought out and an benefit to Fedora going forward. Thank you for taking the time to work through these issues. As a next step, the Board would like to see FESCo and the Working Groups discuss marketing of these products, both individually for each product and collectively as the Fedora project deliverables. The Board, FESCo, WGs, Marketing, Ambassadors and web sites team should come up with a broader marketing/branding plan to make the transition to a three main product deliverable world as clear and effective as possible. We look forward to working with these groups in the near future. -The Board

1 0

Re: default file system, was: Comparison to Workstation Technical Specification
by Bill Nottingham 26 Feb '14

26 Feb '14

Kevin Fenzi (kevin(a)scrye.com) said: > Another aspect of xfs we may want to investigate and get feedback from > filesystem folks is how well xfs works on 32bit these days. > > RHEL7 doesn't have a 32bit version in their beta, so they only need to > support 64bit xfs. Does the fact that we expect to have 32bit > workstation and/or server weigh into this decision any? We expect to have a 32-bit workstation or server? Not trying to troll, but I don't know that any of these were specifically discussed or specified in the products - are there any arches where Fedora currently exists that we don't necessarily care about having a particular product on? (For example, if you expand to secondary arches, I'd question the idea of s390 Workstation.) Bill, who does have a 32-bit x86 server under his home desk...

2 1

Re: default file system, was: Comparison to Workstation Technical Specification
by Chris Murphy 26 Feb '14

26 Feb '14

On Feb 26, 2014, at 8:13 AM, Michael Cronenworth <mike(a)cchtml.com> wrote: > Ext4 has its btrfs conversion tool. Changing from ext4 to XFS, for arguably negligible benefits for Workstations, will make it more difficult for Fedora users to transition to btrfs. It's an unlikely path because a.) by default we put ext4 on LVM; b.) the convert tool uses ext4 block size to set btrfs leaf size; c.) the convert tool doesn't set extref, although it easily could. The last two are a cake walk to change compared to the first. On Feb 26, 2014, at 8:20 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote: > I agree switching from ext4 to XFS is likely not worthwhile. Whether Server WG goes with ext4 or XFS on LVM, it's worthwhile for Workstation WG to mimic it merely due to simplicity because then we don't need separate installers or composes. On Feb 26, 2014, at 8:24 AM, David Cantrell <dcantrell(a)redhat.com> wrote: > > I think filesystem variance across different Fedoras really impacts QA more > than us. We already support a lot of filesystems, but the real hit is the > QA test matrix. QA already tests the file system layouts being discussed. Perhaps the least tested is XFS on LVM only because the XFS test case doesn't specify LVM, so testers probably split and do some plain partition and some on LVM. If Server WG decides on XFS, it effectively increases the Automatic/Guided/easy/default installer path's "Partition Scheme" pop-up from four to five options, and that is a problem. Adamw and I are working on a proposal to reduce these options to one or two: i.e. a WG chosen product specific default, and maybe "one other" which is decided by Base WG or FESCo. Chris Murphy

5 4

Updated Event Invitation: Technical Specification Working Session
by Stephen Gallagher 26 Feb '14

26 Feb '14

BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20140226T180310Z DTSTAMP:20140226T180310Z UID:c9b04c0e-1158-443f-9059-96fb521d882c SUMMARY:Technical Specification Working Session STATUS:CONFIRMED ORGANIZER:mailto:sgallagh@redhat.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:serve r(a)lists.fedoraproject.org RRULE:FREQ=DAILY;UNTIL=20140228T150000Z DTSTART;TZID=America/New_York:20140227T100000 DTEND;TZID=America/New_York:20140227T120000 DESCRIPTION:We need to sit down and hash out the remaining issues on the F edora Server Technical Specification. I am booking two sessions (Thursday and Friday)\, though I hope not to need both.\n\nPlease join us in #fedora -meeting-1 on Thursday if you would like to participate. LOCATION:#fedora-meeting-1 CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:2 END:VEVENT END:VCALENDAR

1 0

Updated Event Invitation: Technical Specification Working Session
by Stephen Gallagher 26 Feb '14

26 Feb '14

BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:19700308T020000 RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:19701101T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11 END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20140226T180107Z DTSTAMP:20140226T180107Z UID:c9b04c0e-1158-443f-9059-96fb521d882c SUMMARY:Technical Specification Working Session STATUS:CONFIRMED ORGANIZER:mailto:sgallagh@redhat.com ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:serve r(a)lists.fedoraproject.org RRULE:FREQ=DAILY;UNTIL=20140217T150000Z DTSTART;TZID=America/New_York:20140227T100000 DTEND;TZID=America/New_York:20140227T120000 DESCRIPTION:We need to sit down and hash out the remaining issues on the F edora Server Technical Specification. I am booking two sessions (Thursday and Friday)\, though I hope not to need both.\n\nPlease join us in #fedora -meeting-1 on Thursday if you would like to participate. LOCATION:#fedora-meeting-1 CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:1 END:VEVENT END:VCALENDAR

1 0

boot.fedoraproject.org as a deliverable
by Chris Murphy 25 Feb '14

25 Feb '14

At boot.fedoraproject.org none of the available downloads are UEFI compatible. There is a UEFI pxe boot test case so it looks like it ought to work, but I thought I'd point out that at the moment it's unclear how to do this on UEFI. [1] http://fedoraproject.org/wiki/QA:Testcase_UEFI_pxeboot (This test case might be outdated as it references bootia32, but we aren't supporting 32-bit EFI right now.) Chris Murphy

2 2

Meeting Minutes / February 25, 2014
by Máirín Duffy 25 Feb '14

25 Feb '14

Summary: * Roll call (adamw, 16:00:51) Target roles for F21 (adamw, 16:06:48) ====================================== * AGREED: Domain Controller is accepted as the "primary blocker * AGREED: Database Server is accepted as the "secondary target" role for Fedora 21 (+9/-0) (adamw, 16:10:04) * AGREED: PostgreSQL is accepted as the "initial" database for Fedora 21 (7 pgsql, 1 mariadb, 1 abstain) (adamw, 16:11:11) Install media and high-level view of default packages (adamw, 16:11:53) ======================================================================= * PRD states "Fedora Server will produce two main installation resources, a netinstall image and an offline install iso image that allows one to install and configure featured roles offline." (adamw, 16:13:29) * AGREED: initial maximum size for offline ISO is 4GB (+5/-0) (adamw, 1:18:45) ** AGREED: one deliverable for Fedora 21 will be a 'traditional install' style ISO image capable of deploying the roles we consider ready for release without a network connection (adamw, 16:32:10) * http://boot.fedoraproject.org/download (nirik, 16:34:26) * AGREED: we also plan a minimal deliverable of some kind for Fedora 21, which could be a 'traditional' netinstall image, a boot.fedoraproject.org-style 'anacondaless' image, or just a variant method of deployment from the 'full' deliverable: this requires further consideration (adamw, 16:46:14) * AGREED: sshd will be installed, enabled and running by default when deploying Fedora Server (adamw, 16:58:01) * https://fedoraproject.org/wiki/Server/Polish_Ideas #3 here is how i added it (mizmo, 17:04:43) Action Items ============ * ACTION: sgallagh to send out a mail regarding 'core dependencies' for discussion (adamw, 17:06:28) * ACTION: sgallagh to send a whenisgood for a follow up meeting later this week to discuss the rest of the things we have to settle (adamw, 17:12:14) * ACTION: sgallagh to send whenisgood request for Thursday/Friday (sgallagh, 17:13:25) Minutes: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014… Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014… Log: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-25/server-wg.2014…

1 0

WG Vote: Server Roles for F21
by Stephen Gallagher 25 Feb '14

25 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We have about a week left to formulate our technical document for Fedora 21. To that end, I'd like to call a formal vote of the Working Group on two of the key points: which two roles to focus on for the initial release. Vote A) "Domain Controller" role is our primary blocker target for Fedora 21. Vote B) "Database Server" roles is our secondary target for Fedora 21 Vote B2) If Vote B is approved: MariaDB or PostgreSQL as our initial database. (This does *not* exclude the possibility of creating a Role for the other one in the future, but it sets our priority for this cycle). If these are approved, we will need to start documenting our technical needs to deliver these Roles. A non-exhaustive list: * Public API for setup and configuration (D-BUS based?) * Packages and meta-packages to support it * List of firewall rules/configuration * List of data to back up; possible API to accomplish this * (Human and non-human) resources needed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMHrYcACgkQeiVVYja6o6ORtgCfTw/ocGzzazXlEVmkVp6uLb0V lE4AnifptRBkNQ11UNFx2jlzvorIaBDw =wO32 -----END PGP SIGNATURE-----

10 10

random suggestion: system_identification from CSI / Fedora Infrastructure
by Matthew Miller 25 Feb '14

25 Feb '14

When you ssh into people.fedoraproject.org, you get some information including this bit: Security Category: Low Primary Contact: Fedora Admins - admin(a)fedoraproject.org Purpose: Provide hosting space for Fedora contributors and Fedora Planet This comes from http://infrastructure.fedoraproject.org/csi/security-policy/en-US/html-sing… That's pretty neat. A lot of big organizations may have policies and a system like that, but it strikes me as something that would be neat to integrate into Fedora Server by default. -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

server February 2014