Re: Release criteria proposal: networking requirements
On Mon, Feb 28, 2022 at 12:37 PM Adam Williamson wrote: > > So, uh, we sorta forgot about this. Kamil approved this draft, but > nobody else gave any feedback on it. This topic is still relevant and > we have a proposed VPN blocker today, so...any more feedback on this > draft? I think it's sound enough to start using. I'm sure we'll find all sorts of edge cases to argue over and eventually fix. That's the Fedora Way™. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Release criteria proposal: networking requirements
On Fri, 2020-08-28 at 16:59 -0700, Adam Williamson wrote: > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > > Hi folks! > > > > So at this week's blocker review meeting, the fact that we don't have > > explicit networking requirements in the release criteria really started > > to bite us. In the past we have squeezed networking-related issues in > > under other criteria, but for some issues that's really difficult, > > notably VPN issues. So, we agreed we should draft some explicit > > networking criteria. > > Update: here's a second draft with feedback so far incorporated, thanks > to everyone. Still mulling over whether/how to split it more across > milestones. > > === Network requirements === > > Each of these requirements apply to both installer and installed system > environments. For any given installer environment, the 'default network > configuration tools' are considered to be those the installer documents > as supported ways to configure networking (e.g. for anaconda-based > environments, configuration via kernel command line options, a > kickstart, or interactively in anaconda itself are included). > > Basic networking > > It must be possible to establish both IPv4 and IPv6 network connections > using both typical router-provided addressing systems (e.g. DHCP on > IPv4 or SLAAC or IPv6) and static addressing. The default network > configuration tools for the console, for release-blocking desktops and > for installer environments must work well enough to allow typical > network connection configuration operations without major workarounds. > Standard network functions such as address resolution and connections > with common protocols such as ping, HTTP and ssh must work as expected. > > Footnote titled "Supported hardware": Supported network hardware is > hardware for which the Fedora kernel includes drivers and, where > necessary, for which a firmware package is available. If support for a > commonly-used piece or type of network hardware that would usually be > present is omitted, that may constitute a violation of this criterion, > after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- > issues|normal factors for hardware-dependent issues]]. Similarly, > violations of this criteria that are hardware or configuration > dependent are, as usual, subject to consideration of those factors when > determining whether they are release-blocking > > VPN connections > > Using the default network configuration tools for the console and for > release-blocking desktops, it must be possible to establish a working > connection to common OpenVPN, openconnect-supported and vpnc-supported > VPN servers with typical configurations. > > Footnote titled "Supported servers and configurations": As there are > many different VPN server applications and configurations, blocker > reviewers must use their best judgment in determining whether > violations of this criterion are likely to be encountered commonly > enough to block a release, and if so, at which milestone. As a general > principle, the more people are likely to use affected servers and the > less complicated the configuration required to hit the bug, the more > likely it is to be a blocker. So, uh, we sorta forgot about this. Kamil approved this draft, but nobody else gave any feedback on it. This topic is still relevant and we have a proposed VPN blocker today, so...any more feedback on this draft? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Release criteria proposal: networking requirements
On Sat, Aug 29, 2020 at 1:59 AM Adam Williamson wrote: > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > > Hi folks! > > > > So at this week's blocker review meeting, the fact that we don't have > > explicit networking requirements in the release criteria really started > > to bite us. In the past we have squeezed networking-related issues in > > under other criteria, but for some issues that's really difficult, > > notably VPN issues. So, we agreed we should draft some explicit > > networking criteria. > > Update: here's a second draft with feedback so far incorporated, thanks > to everyone. Still mulling over whether/how to split it more across > milestones. > > === Network requirements === > > Each of these requirements apply to both installer and installed system > environments. For any given installer environment, the 'default network > configuration tools' are considered to be those the installer documents > as supported ways to configure networking (e.g. for anaconda-based > environments, configuration via kernel command line options, a > kickstart, or interactively in anaconda itself are included). > > Basic networking > > It must be possible to establish both IPv4 and IPv6 network connections > using both typical router-provided addressing systems (e.g. DHCP on > IPv4 or SLAAC or IPv6) and static addressing. The default network > configuration tools for the console, for release-blocking desktops and > for installer environments must work well enough to allow typical > network connection configuration operations without major workarounds. > Standard network functions such as address resolution and connections > with common protocols such as ping, HTTP and ssh must work as expected. > > Footnote titled "Supported hardware": Supported network hardware is > hardware for which the Fedora kernel includes drivers and, where > necessary, for which a firmware package is available. If support for a > commonly-used piece or type of network hardware that would usually be > present is omitted, that may constitute a violation of this criterion, > after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- > issues|normal factors for hardware-dependent issues]]. Similarly, > violations of this criteria that are hardware or configuration > dependent are, as usual, subject to consideration of those factors when > determining whether they are release-blocking > > VPN connections > > Using the default network configuration tools for the console and for > release-blocking desktops, it must be possible to establish a working > connection to common OpenVPN, openconnect-supported and vpnc-supported > VPN servers with typical configurations. > > Footnote titled "Supported servers and configurations": As there are > many different VPN server applications and configurations, blocker > reviewers must use their best judgment in determining whether > violations of this criterion are likely to be encountered commonly > enough to block a release, and if so, at which milestone. As a general > principle, the more people are likely to use affected servers and the > less complicated the configuration required to hit the bug, the more > likely it is to be a blocker. > Sounds good to me. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Sat, Aug 29, 2020 at 1:57 AM Adam Williamson wrote: > On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote: > > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson > > wrote: > > > > > > Basic networking > > > > > > It must be possible to establish both IPv4 and IPv6 network connections > > > using DHCP and static addressing. The default network configuration > > > tools for the console and for release-blocking desktops must work well > > > enough to allow typical network connection configuration operations > > > without major workarounds. Standard network functions such as address > > > resolution and connections with common protocols such as ping, HTTP and > > > ssh must work as expected. > > > > What about mDNS? > > ehhh > > I am probably a bit biased on this front because I always found mDNS to > be a pile of garbage and gave up trying to use it a while back. :P But > if a significant amount of people are actually using it and relying on > it, adding it might make sense. Anyone else have input on this? Who out > there does use mDNS? > I contact my machines (even VMs) through .local every day, I'd be very angry if it didn't work, and I consider myself a significant amount of people ;o) ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy wrote: > The IPP Everywhere specification requires clients to support DNS-SD > (mDNS is part of that) or WS-Discovery. Printers are required to > support both DNS-SD and WS-Discovery. Avahi and systemd-resolved > support DNS-SD, functionally equating DNS-SD and mDNS. From the spec: "Printers MUST publish a text (TXT) record that provides service information over mDNS. Printers that support dynamic DNS updates MUST publish separate TXT records for each domain that is updated." I'm not completely certain, but I'm wondering whether it's possible to print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working on the client. Even having the IP address might not be enough. I guess one way to test it would be to run the printing test case with an IPP Everywhere printer, and try to print with avahi stopped. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
[Sorry for the double post, somewhere along the way desktop@ and kde@ were dropped, so I'm re-adding them and that means double post for test@ and devel@.] Re: add working mDNS to the criterion The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS. Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met. It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing. Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, Aug 28, 2020 at 5:56 PM Adam Williamson wrote: > > On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote: > > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson > > wrote: > > > > > > Basic networking > > > > > > It must be possible to establish both IPv4 and IPv6 network connections > > > using DHCP and static addressing. The default network configuration > > > tools for the console and for release-blocking desktops must work well > > > enough to allow typical network connection configuration operations > > > without major workarounds. Standard network functions such as address > > > resolution and connections with common protocols such as ping, HTTP and > > > ssh must work as expected. > > > > What about mDNS? > > ehhh > > I am probably a bit biased on this front because I always found mDNS to > be a pile of garbage and gave up trying to use it a while back. :P But > if a significant amount of people are actually using it and relying on > it, adding it might make sense. Anyone else have input on this? Who out > there does use mDNS? The IPP Everywhere specification requires clients to support DNS-SD (mDNS is part of that) or WS-Discovery. Printers are required to support both DNS-SD and WS-Discovery. Avahi and systemd-resolved support DNS-SD, functionally equating DNS-SD and mDNS. Final release criterion says printing via the generic IPP driver must work. This implies discovery or you can't print. Or accept a craptastic user experience by fudging the requirement to say, well as long as an IP address works, the criterion is met. It's even less of a leap if folks can't discover other services like SMB shares. That's more common than printing. Between avahi and systemd-resolved, I'm not sure which one is more dependable for blocking on. Or whether their maintainers would be on board with such a criterion. At least for F33, Avahi is what we're using on desktops for this. Both resolve and respond are disabled in systemd-resolved so if it's better to do this with systemd-resolved, then it probably needs a Fedora 34 feature proposal. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > Hi folks! > > So at this week's blocker review meeting, the fact that we don't have > explicit networking requirements in the release criteria really started > to bite us. In the past we have squeezed networking-related issues in > under other criteria, but for some issues that's really difficult, > notably VPN issues. So, we agreed we should draft some explicit > networking criteria. Update: here's a second draft with feedback so far incorporated, thanks to everyone. Still mulling over whether/how to split it more across milestones. === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). Basic networking It must be possible to establish both IPv4 and IPv6 network connections using both typical router-provided addressing systems (e.g. DHCP on IPv4 or SLAAC or IPv6) and static addressing. The default network configuration tools for the console, for release-blocking desktops and for installer environments must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking VPN connections Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VPN servers with typical configurations. Footnote titled "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Thu, 2020-08-27 at 10:06 -0600, Chris Murphy wrote: > On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson > wrote: > > > > Basic networking > > > > It must be possible to establish both IPv4 and IPv6 network connections > > using DHCP and static addressing. The default network configuration > > tools for the console and for release-blocking desktops must work well > > enough to allow typical network connection configuration operations > > without major workarounds. Standard network functions such as address > > resolution and connections with common protocols such as ping, HTTP and > > ssh must work as expected. > > What about mDNS? ehhh I am probably a bit biased on this front because I always found mDNS to be a pile of garbage and gave up trying to use it a while back. :P But if a significant amount of people are actually using it and relying on it, adding it might make sense. Anyone else have input on this? Who out there does use mDNS? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Thu, Aug 27, 2020 at 6:08 PM Chris Murphy wrote: > What about mDNS? > > Something to the effect that if it's installed and enabled by a > default package set for an edition, it should work (resolve and > respond). That means it would apply to Workstation and KDE. It > wouldn't apply to Cloud, or Server. I'm not sure if IoT enables it. > That sounds good to me, but it seems to belong to the Final milestone rather than Basic or Beta. Can be proposed separately. ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Thu, Aug 27, 2020 at 8:37 PM Adam Williamson
wrote:
> > > It must be possible to establish both IPv4 and IPv6 network connections
> > > using DHCP and static addressing. The default network configuration
> > > tools for the console and for release-blocking desktops must work well
> > > enough to allow typical network connection configuration operations
> > > without major workarounds.
> >
> >
> > I'm a bit confused here. If you specifically say "for the console and for
> > release-blocking desktops", does that mean it doesn't apply to the
> > installer? Because at the top you say it applies to both, but here it
> > sounds very specific.
>
> No, I didn't intend that, I was just making sure to cover both console
> and desktop. We can make it "for the console, for release-blocking
> desktops and for installer environments" if you like.
>
I guess it would help to avoid the confusion.
> > If it applies to the installer, does this mean that *all* ways to
> configure
> > this in the installer must work (i.e. kernel cmdline, kickstart, gui,
> tui)?
> > That seems quite demanding for a Basic criterion.
>
> That's kind of a tricky one, because I agree it's broad, but on the
> other hand there are situations where you kinda need each of them. You
> can't always have a monitor and a human to do it interactively in the
> install environment, and if you're retrieving a kickstart or the
> installer environment itself (after a PXE boot, say) over the network,
> you need the kernel cmdline case to work.
> So, I mean, it's difficult. We *could* split it across Basic and Final,
> but I can't immediately see a clear rationale for how to do that. Any
> ideas? I guess we could look at what the criteria require for things
> like kickstart and PXE boot and try to align them...
>
PXE is Beta, kickstart *delivery* is Beta. There are no further criteria
related to kickstarts, I think I had I have an #action to propose that
criterion that's a few years old now.
The "obvious" split would be to require user-related actions (gui/tui)
sooner and professional-related actions later (kickstarts, cmdline). But at
the same time, specifically for the installer, the professional-related
actions are pretty important for QA to deliver a decent test coverage.
Which coincidentally is also Beta ("Bug hinders execution of required Beta
test plans or dramatically reduces test coverage"), but that doesn't feel
right, if we truly want to aim for having Basic criteria valid all the time
and applying Basic tests during package gating.
In the past, user actions took precedence over e.g. mass deployment
features, because we tested manually first among local testers, and only
then made public Alpha/Beta/Final releases for the mass audience. But with
continuous testing through automation, the picture is reversed, and we need
features like kickstarts and kernel cmdline options sooner than we need
manual user actions.
So... I don't know, this is tricky :) Putting it all under Basic is of
course ideal for us, and since there's still no meaningful difference
between Basic and Beta, I guess it's good enough for now. Once there is
some difference (like build gating rejection when these criteria are
violated), the installer team might push for moving some of those
requirements to a later stage.
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Thu, 2020-08-27 at 15:44 +0200, Kamil Paral wrote: > On Sat, Aug 22, 2020 at 2:12 AM Adam Williamson > wrote: > > > === Network requirements === > > > > Each of these requirements apply to both installer and installed system > > environments. For any given installer environment, the 'default network > > configuration tools' are considered to be those the installer documents > > as supported ways to configure networking (e.g. for anaconda-based > > environments, configuration via kernel command line options, a > > kickstart, or interactively in anaconda itself are included). > > > > Basic networking > > > > It must be possible to establish both IPv4 and IPv6 network connections > > using DHCP and static addressing. The default network configuration > > tools for the console and for release-blocking desktops must work well > > enough to allow typical network connection configuration operations > > without major workarounds. > > > I'm a bit confused here. If you specifically say "for the console and for > release-blocking desktops", does that mean it doesn't apply to the > installer? Because at the top you say it applies to both, but here it > sounds very specific. No, I didn't intend that, I was just making sure to cover both console and desktop. We can make it "for the console, for release-blocking desktops and for installer environments" if you like. > If it applies to the installer, does this mean that *all* ways to configure > this in the installer must work (i.e. kernel cmdline, kickstart, gui, tui)? > That seems quite demanding for a Basic criterion. That's kind of a tricky one, because I agree it's broad, but on the other hand there are situations where you kinda need each of them. You can't always have a monitor and a human to do it interactively in the install environment, and if you're retrieving a kickstart or the installer environment itself (after a PXE boot, say) over the network, you need the kernel cmdline case to work. So, I mean, it's difficult. We *could* split it across Basic and Final, but I can't immediately see a clear rationale for how to do that. Any ideas? I guess we could look at what the criteria require for things like kickstart and PXE boot and try to align them... > > Using the default network configuration tools for the console and for > > release-blocking desktops, it must be possible to establish a working > > connection to common OpenVPN, openconnect-supported and vpnc-supported > > VNC servers with typical configurations. > > > > Just out of curiosity, why isn't this "OpenVPN, openconnect and vpnc VPN > servers", but instead it is "-supported" for the latter two? Well, openconnect supports multiple different VPN servers. "OpenConnect is an SSL VPN client initially created to support Cisco's AnyConnect SSL VPN. It has since been ported to support the Juniper SSL VPN (which is now known as Pulse Connect Secure), and the Palo Alto Networks GlobalProtect SSL VPN." vpnc only really supports Cisco IPsec servers, but they aren't really called "vpnc VPN servers". vpnc is just the name of the third-party client for such VPNs that NetworkManager-vpnc wraps. So "vpnc-supported servers" seems more correct than "vpnc servers". Looking at https://wiki.gnome.org/Projects/NetworkManager/VPN , there are several other plugins my draft doesn't list. I'm not sure if any of them is common enough that we should block on it. Anyone have an idea about that? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, Aug 21, 2020 at 6:11 PM Adam Williamson wrote: > > Basic networking > > It must be possible to establish both IPv4 and IPv6 network connections > using DHCP and static addressing. The default network configuration > tools for the console and for release-blocking desktops must work well > enough to allow typical network connection configuration operations > without major workarounds. Standard network functions such as address > resolution and connections with common protocols such as ping, HTTP and > ssh must work as expected. What about mDNS? Something to the effect that if it's installed and enabled by a default package set for an edition, it should work (resolve and respond). That means it would apply to Workstation and KDE. It wouldn't apply to Cloud, or Server. I'm not sure if IoT enables it. -- Chris Murphy ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Sat, Aug 22, 2020 at 2:12 AM Adam Williamson wrote: > === Network requirements === > > Each of these requirements apply to both installer and installed system > environments. For any given installer environment, the 'default network > configuration tools' are considered to be those the installer documents > as supported ways to configure networking (e.g. for anaconda-based > environments, configuration via kernel command line options, a > kickstart, or interactively in anaconda itself are included). > > Basic networking > > It must be possible to establish both IPv4 and IPv6 network connections > using DHCP and static addressing. The default network configuration > tools for the console and for release-blocking desktops must work well > enough to allow typical network connection configuration operations > without major workarounds. I'm a bit confused here. If you specifically say "for the console and for release-blocking desktops", does that mean it doesn't apply to the installer? Because at the top you say it applies to both, but here it sounds very specific. If it applies to the installer, does this mean that *all* ways to configure this in the installer must work (i.e. kernel cmdline, kickstart, gui, tui)? That seems quite demanding for a Basic criterion. > Standard network functions such as address > resolution and connections with common protocols such as ping, HTTP and > ssh must work as expected. > > Footnote titled "Supported hardware": Supported network hardware is > hardware for which the Fedora kernel includes drivers and, where > necessary, for which a firmware package is available. If support for a > commonly-used piece or type of network hardware that would usually be > present is omitted, that may constitute a violation of this criterion, > after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- > issues|normal factors for hardware-dependent issues]]. Similarly, > violations of this criteria that are hardware or configuration > dependent are, as usual, subject to consideration of those factors when > determining whether they are release-blocking > > VPN connections > > Using the default network configuration tools for the console and for > release-blocking desktops, it must be possible to establish a working > connection to common OpenVPN, openconnect-supported and vpnc-supported > VNC servers with typical configurations. > Just out of curiosity, why isn't this "OpenVPN, openconnect and vpnc VPN servers", but instead it is "-supported" for the latter two? > > Footnote title "Supported servers and configurations": As there are > many different VPN server applications and configurations, blocker > reviewers must use their best judgment in determining whether > violations of this criterion are likely to be encountered commonly > enough to block a release, and if so, at which milestone. As a general > principle, the more people are likely to use affected servers and the > less complicated the configuration required to hit the bug, the more > likely it is to be a blocker. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > ___ > desktop mailing list -- desk...@lists.fedoraproject.org > To unsubscribe send an email to desktop-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org > ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Tue, 2020-08-25 at 16:11 -0700, Adam Williamson wrote: > On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote: > > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > > > VPN connections > > > > > > > > > > > > Using the default network configuration tools for the console and > > > for > > > > > > release-blocking desktops, it must be possible to establish a > > > working > > > > > > connection to common OpenVPN, openconnect-supported and vpnc- > > > supported > > > > > > VNC servers with typical configurations. > > > > VNC == VPN? > > Oh, yes. Thanks. > > > Also, should we add WireGuard to this list for future-proofing? > > It doesn't really make sense to add things to the release criteria > for > future proofing. If it's important *now* we should add it. Otherwise, > no. > > Do NetworkManager and its current KDE and GNOME front ends support it > currently? IIRC not - wireguard-tools is available, but setting up a connection is manual or needs to use the GUI/CLI from a VPN provider such as Mullvad https://www.wireguard.com/quickstart/ https://mullvad.net/nl/help/install-mullvad-app-linux/ https://mullvad.net/en/help/how-use-mullvad-cli/ -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote: > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > > VPN connections > > > > > > > > Using the default network configuration tools for the console and for > > > > release-blocking desktops, it must be possible to establish a working > > > > connection to common OpenVPN, openconnect-supported and vpnc- > > supported > > > > VNC servers with typical configurations. > > VNC == VPN? Oh, yes. Thanks. > Also, should we add WireGuard to this list for future-proofing? It doesn't really make sense to add things to the release criteria for future proofing. If it's important *now* we should add it. Otherwise, no. Do NetworkManager and its current KDE and GNOME front ends support it currently? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > VPN connections > > > > Using the default network configuration tools for the console and for > > release-blocking desktops, it must be possible to establish a working > > connection to common OpenVPN, openconnect-supported and vpnc- > supported > > VNC servers with typical configurations. VNC == VPN? Also, should we add WireGuard to this list for future-proofing? Thanks, -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
That all sounds reasonable to me. Does wifi fall into this as well? Stephen On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote: > Hi folks! > > So at this week's blocker review meeting, the fact that we don't have > explicit networking requirements in the release criteria really > started > to bite us. In the past we have squeezed networking-related issues in > under other criteria, but for some issues that's really difficult, > notably VPN issues. So, we agreed we should draft some explicit > networking criteria. > > This turns out to be a big area and quite hard to cover (who'd've > thought!), but here is at least a first draft for us to start from. > My > proposal would be to add this to the Basic criteria. I have left out > some wikitext stuff from the proposal for clarity; I'd add it back in > on actually applying the proposed changes. It's just formatting > stuff, > nothing that'd change the meaning. Anyone have thoughts, complaints, > alternative approaches, supplements? Thanks! > > === Network requirements === > > Each of these requirements apply to both installer and installed > system > environments. For any given installer environment, the 'default > network > configuration tools' are considered to be those the installer > documents > as supported ways to configure networking (e.g. for anaconda-based > environments, configuration via kernel command line options, a > kickstart, or interactively in anaconda itself are included). > > Basic networking > > It must be possible to establish both IPv4 and IPv6 network > connections > using DHCP and static addressing. The default network configuration > tools for the console and for release-blocking desktops must work > well > enough to allow typical network connection configuration operations > without major workarounds. Standard network functions such as address > resolution and connections with common protocols such as ping, HTTP > and > ssh must work as expected. > > Footnote titled "Supported hardware": Supported network hardware is > hardware for which the Fedora kernel includes drivers and, where > necessary, for which a firmware package is available. If support for > a > commonly-used piece or type of network hardware that would usually be > present is omitted, that may constitute a violation of this > criterion, > after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- > issues|normal factors for hardware-dependent issues]]. Similarly, > violations of this criteria that are hardware or configuration > dependent are, as usual, subject to consideration of those factors > when > determining whether they are release-blocking > > VPN connections > > Using the default network configuration tools for the console and for > release-blocking desktops, it must be possible to establish a working > connection to common OpenVPN, openconnect-supported and vpnc- > supported > VNC servers with typical configurations. > > Footnote title "Supported servers and configurations": As there are > many different VPN server applications and configurations, blocker > reviewers must use their best judgment in determining whether > violations of this criterion are likely to be encountered commonly > enough to block a release, and if so, at which milestone. As a > general > principle, the more people are likely to use affected servers and the > less complicated the configuration required to hit the bug, the more > likely it is to be a blocker. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . > net > http://www.happyassassin.net > ___ > test mailing list -- test@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Release criteria proposal: networking requirements
Hi folks! So at this week's blocker review meeting, the fact that we don't have explicit networking requirements in the release criteria really started to bite us. In the past we have squeezed networking-related issues in under other criteria, but for some issues that's really difficult, notably VPN issues. So, we agreed we should draft some explicit networking criteria. This turns out to be a big area and quite hard to cover (who'd've thought!), but here is at least a first draft for us to start from. My proposal would be to add this to the Basic criteria. I have left out some wikitext stuff from the proposal for clarity; I'd add it back in on actually applying the proposed changes. It's just formatting stuff, nothing that'd change the meaning. Anyone have thoughts, complaints, alternative approaches, supplements? Thanks! === Network requirements === Each of these requirements apply to both installer and installed system environments. For any given installer environment, the 'default network configuration tools' are considered to be those the installer documents as supported ways to configure networking (e.g. for anaconda-based environments, configuration via kernel command line options, a kickstart, or interactively in anaconda itself are included). Basic networking It must be possible to establish both IPv4 and IPv6 network connections using DHCP and static addressing. The default network configuration tools for the console and for release-blocking desktops must work well enough to allow typical network connection configuration operations without major workarounds. Standard network functions such as address resolution and connections with common protocols such as ping, HTTP and ssh must work as expected. Footnote titled "Supported hardware": Supported network hardware is hardware for which the Fedora kernel includes drivers and, where necessary, for which a firmware package is available. If support for a commonly-used piece or type of network hardware that would usually be present is omitted, that may constitute a violation of this criterion, after consideration of the [[Blocker_Bug_FAQ|hardware-dependent- issues|normal factors for hardware-dependent issues]]. Similarly, violations of this criteria that are hardware or configuration dependent are, as usual, subject to consideration of those factors when determining whether they are release-blocking VPN connections Using the default network configuration tools for the console and for release-blocking desktops, it must be possible to establish a working connection to common OpenVPN, openconnect-supported and vpnc-supported VNC servers with typical configurations. Footnote title "Supported servers and configurations": As there are many different VPN server applications and configurations, blocker reviewers must use their best judgment in determining whether violations of this criterion are likely to be encountered commonly enough to block a release, and if so, at which milestone. As a general principle, the more people are likely to use affected servers and the less complicated the configuration required to hit the bug, the more likely it is to be a blocker. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
