F20 Self Contained Change: Ruby on Rails 4.0
by Jaroslav Reznik
= Proposed Self Contained Change: Ruby on Rails 4.0 =
https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0
Change owner(s): Vít Ondruch <vondruch(a)redhat.com>, Josef Stříbný
<jstribny(a)redhat.com>, ruby-sig(a)lists.fedoraproject.org
Ruby on Rails 4.0 is the latest version of well know web framework written in
Ruby.
== Detailed description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep pace with
it. Therefore the whole Ruby on Rails stack should be updated from 3.2 in
Fedora 19 to 4.0 (latest version) in Fedora 20. This will ensure that all the
Ruby developers using Fedora have the latest and greatest RPM-packaged Ruby on
Rails.
== Scope ==
Proposal owners:
* The whole Rails stack has to be updated
* New additional gems will have to be packaged
* Some dependencies of the Rails stack will need update
For the list, see [1]
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_4.0#Scope
10 years, 9 months
Reminder: Change Proposals Submission deadline is tomorrow!
by Jaroslav Reznik
Greetings!
The Change Proposals Submission deadline is tomorrow, 2013-07-16 [1]. Please
send your proposals for Wrangler's review (to be announced asap) and help us
to coordinate Fedora 20 release! The final schedule will be based on the needs
of accepted Changes.
See How to's on https://fedoraproject.org/wiki/Changes/Policy
After this deadline new Change Proposals would require FESCo exception. I can
see a lot of Changes still being incomplete, don't forget to change the
category by Tuesday!
FYI: FESCo on the last meeting approved the Change Proposals escalation
process. If you're asked by FESCo member(s) or Wrangler to change your Change
Proposal to the System Wide category, please do so and fill in required details
in the Change page. Thanks.
Jaroslav
[1] https://fedoraproject.org/wiki/Releases/20/Schedule
10 years, 9 months
F20 System Wide Change: Visible Cloud
by Jaroslav Reznik
= Proposed System Wide Change: Visible Cloud =
https://fedoraproject.org/wiki/Changes/VisibleCloud
Change owner(s): Matthew Miller <mattdm at fedoraproject org>
With Fedora 19's First Class Cloud Images feature [1], we have Amazon EC2 and
downloadable cloud images (in qcow2 and raw.xz format) produced and released
together with the traditional desktop installer and and livecd images. Now,
let's go to the next level and present the cloud images as equal options.
== Detailed description ==
This involves three key changes. They are not significant changes to other
packages, but since this has implications for the distribution as a whole, I
thought it best considered as bigger than a self-contained change.
1. Refactoring of the Fedora web site to put the cloud image on equal footing
with the desktop image download. The new F19 cloud images page [2] is very
nice thanks to the hard work of the web team, but unfortunately, in order to
find it, one has to go down into the cellar, into a disused lavatory with a
sign on the door saying Beware of the Leopard. Let's put it on display in the
metaphorical front lobby.
2. Creating specific release criteria and tests for basic cloud image
functionality in, at least, Amazon EC2 and OpenStack. (Tests for smaller
public cloud services could be added once those services gain the ability for
us to provide official images directly. Tests for Eucalyptus and other IaaS
software could be added as well.)
3. Building images in Koji using virtualization and Anaconda, rather than
using a chroot-based appliance-creator. This will ensure that the cloud image
is more in line with The Real Fedora.
== Scope ==
Proposal owner: Coordination; working with web designers and documentation
writers to develop the new presentation, working with QA to develop criteria
and tests, and working with release engineering to land the changes to image
building. I plan to be actively involved in all of these.
Other developers: This will probably require a overhaul of the Get Fedora
website, as that is current primarily focused on the desktop download.
Release engineering: Yes, Jay Greguske, Andrew Thomas, and I are working on
the improvements to the image build system and coordinating with Dennis
Gilmore.
Policies and guidelines: As noted, QA guidelines will need to be updated.
[1] https://fedoraproject.org/wiki/Features/FirstClassCloudImages
[2] http://fedoraproject.org/en/get-fedora-options#clouds
10 years, 9 months
F20 Self Contained Change: Role based access control with libvirt
by Jaroslav Reznik
= Proposed Self Contained Change: Role based access control with libvirt =
https://fedoraproject.org/wiki/Changes/Virt_ACLs
Change owner(s): Daniel P. Berrange <berrange(a)redhat.com>, Cole Robinson
<crobinso(a)redhat.com>
Allow role based access control with libvirt.
== Detailed description ==
Libvirt role based access control will allow fine grained access control like
'user FOO can only start/stop/pause vm BAR', but for all libvirt APIs and
objects.
== Scope ==
Proposal owners:
* 90% of the work is already in rawhide
* Documentation needs to be written
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
10 years, 9 months
F20 System Wide Change: SSD cache
by Jaroslav Reznik
= Proposed System Wide Change: SSD cache =
https://fedoraproject.org/wiki/Changes/SSD_cache
Change owner(s): Rolf Fokkens <rolf(a)rolffokkens.nl>
Using recent kernel (3.9 and later) features for (fast) SSD caching of (slow)
ordinary hard disks.
== Detailed description ==
Recent Linux kernels support the use of Solid State Drives as caches for
rotational hard disks. Because the high cost per GB for SSD devices this
feature may bring the best of both: fast end big yet affordable storage
capacity. Linux kernel 3.9 introduced dm-cache, kernel 3.10 introduces bcache.
== Scope ==
Proposal owners: Enable caching features in new kernels
Other developers: Support the caching features in their respective packages.
Special focus should be on making the system boot from a cached root FS.
Release engineering: All packages should operate in close harmony te make this
work. Only a rebuild of the relevant packages is required.
Policies and guidelines: No changes I think.
10 years, 9 months
F20 System Wide Change: No Default Syslog
by Jaroslav Reznik
= Proposed System Wide Change: No Default Syslog =
https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
Miller <mattdm at fedoraproject org>
No longer install a traditional syslog service by default. (Specifically,
remove rsyslog from the @core or @standard groups in comps.)
The systemd journal will be the default logging solution. Rsyslog, Syslog-NG,
and even traditional sysklogd will continue to cover use cases outside of the
default.
== Detailed description ==
Let's change the default install to no longer install a syslog service by
default — let's remove rsyslog from the "comps" default.
The journal has been around for a few releases and is well tested. F19 already
enabled persistent journal logging on disk, thus all logs have been stored
twice on disk, once in journal files and once in /var/log/messages. This
feature hence recommends no longer installing rsyslog by default, leaving only
the journal in place.
rsyslog will remain the recommended option to install if users require
/var/log/messages, need support for the syslog network protocol, or need to
enforce strict data lifecycle policies. It's sufficient to install and start
rsyslog to get /var/log/messages and BSD syslog support.
Also see previous attempt: [1] and previous mailing list discussion at [2]
[1] https://fedoraproject.org/wiki/Features/systemd-journal
[2] https://lists.fedoraproject.org/pipermail/devel/2012-October/172682.html
== Scope ==
Simply remove "rsyslog" from all default install groups in "comps".
Packages which strictly require /var/log/messages to exist might need updating
to gain dependencies on some kind of syslog daemon (but they needed that
before too, so this is mostly just bugfixing that's useful anyway). If any of
the packages in the default install is one of those, we need to look at it in
detail, and find a solution. However, currently no package of the default
install is requiring a syslog implementation.
Some tools such as logcheck might need to be updated to process data from the
journal instead of /var/log/message. This should be fairily easy as
"journalctl" generates the same output as "cat /var/log/messages" previously
did.
Proposal owners: Commit a change to "comps" to remove "rsyslog" from it. Drop
in a file /var/log/README informing users where the log files went, and how do
get to the same data as before.
Other developers: logcheck needs updating to stay useful. It needs to grep
through the output of "journalctl", rather than /var/log/messages.
Release engineering: nothing really.
Policies and guidelines: Guidelines should clarify that /var/log/message
doesn't exist on many systems, but that was already the case before -- so
little changes. QA should add a few tests and release criteria about journal
functionality.
Note that logrotate should stay in the default install, as it is required to
rotate wtmp and btmp (the journal synchronously rotates before writing and
does not require logrotate for operation).
10 years, 9 months
F20 System Wide Change: No Default Sendmail
by Jaroslav Reznik
= Proposed System Wide Change: No Default Sendmail =
https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
Change owner(s): Lennart Poettering <lennart at poettering net>, Matthew
Miller <mattdm at fedoraproject org>
No longer install an MTA by default. (Specifically let's remove sendmail from
@core and @standard comps groups.)
== Detailed description ==
Let's change the default install to no longer install an MTA by default.
Specifically, let's remove sendmail from the @standard and @core group.
On today's Internet most SMTP hosts do not accept mail from a server which is
not configured as a mail exchange for a real domain, hence the default
configuration of sendmail is seldom useful. Even if the server is not tied to a
real mail domain, it can be configured to authenticate as a user on the target
server, but again, this requires explicit configuration on both ends and is
fairly awkward. Something that doesn't work without manual configuration should
not be in the default install.
Most MUAs we ship (especially those we install by default) do not deliver to a
local MTA anyway but rather include an SMTP client. Usually, they will not
pick up mail delivered to local users. This means that unless the user knows
about local mail and takes steps to receive local mail addressed to root, such
messages are likely to be ignored.
On top of that, sendmail has always been a quite surprising choice for an MTA,
as most administrators tend to prefer mail systems such as Postfix or Exim
these days, and Sendmail appears to be quite arcane to most.
Administrators should install the MTA of their choice after installation (or
via kickstart) and sendmail should not be the default anymore.
Many other distributions do not install an MTA by default anymore, and so
should we. Running systems without MTA is already widely tested.
The various tools (such as cron) which previously required a local MTA for
operation have been updated already to deliver their job output to syslog
rather than sendmail, which is a good default.
Also see the previous attempt:
https://fedoraproject.org/wiki/Features/NoDefaultMTA
== Scope ==
Simply remove "sendmail" from all default install groups in "comps".
Packages which strictly require a MTA to run might need updating to gain
dependencies on "server(smtp)" (but they needed that before too, so this is
mostly just bugfixing that's useful anyway). If any of the packages in the
default install is one of those, we need to look at it in detail, and find a
solution. However, currently no package of the default install is requiring an
MTA.
Proposal owners: Commit a change to "comps" to remove "sendmail" from it.
Other developers: logwatch/logcheck might need updating to not require an MTA
for delivering log changes. Some packages might need a dependency on
"server(smtp)" added.
Release engineering: nothing really.
Policies and guidelines: nothing really. Maybe the guidelines should clarify
that /usr/bin/sendmail doesn't exist on many systems, but that was already the
case before -- so little changes.
10 years, 9 months
F20 Self Contained Change: VM Snapshot UI with virt-manager
by Jaroslav Reznik
= Proposed Self Contained Change: VM Snapshot UI with virt-manager =
https://fedoraproject.org/wiki/Changes/Virt_Manager_Snapshots
Change owner(s): Cole Robinson <crobinso(a)redhat.com>
Add UI to virt-manager for easily managing VM snapshots.
== Detailed description ==
qemu and libvirt have all the major pieces in place for performing safe VM
snapshots/checkpoints, however there isn't any simple discoverable UI. This
feature will track adding that UI to virt-manager, and any other virt stack
bits that need to be fixed/improved.
== Scope ==
Proposal owners:
* Verify that all the libvirt APIs are fully implemented, some pieces were
missing at last check.
*Implement virt-manager UI
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
10 years, 9 months
F20 Self Contained Change: ARM on x86 with libvirt/virt-manager
by Jaroslav Reznik
= Proposed Self Contained Change: ARM on x86 with libvirt/virt-manager =
https://fedoraproject.org/wiki/Changes/Virt_ARM_on_x86
Change owner(s): Cole Robinson <crobinso(a)redhat.com>
Fix running ARM VMs on x86 hosts using standard libvirt tools libvirt virsh,
virt-manager and virt-install.
== Detailed description ==
qemu has an ARM emulator that works well and is actively used in the Fedora
ARM effort. However libvirt and virt-manager currently have issues launching
qemu-system-arm VMs, mostly by encoding x86 assumptions in the generated
command line that cause qemu-system-arm to fail to start. Let's fix it!
== Scope ==
Proposal owners:
1. Get fixed virt-manager and libvirt packages into Fedora by the feature
freeze
2.Fix issues in libvirt with generating qemu-system-arm command lines
* We may only target a single machine type for this, need to determine [1]
3. Fix virt-manager to not encode incorrect device types like 'ide' [2]
4. Optionally identify any UI defaults that can be improved to handle this
case
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=807538
[2] https://bugzilla.redhat.com/show_bug.cgi?id=806105
10 years, 9 months
F20 Self Contained Change: Yesod Web Framework
by Jaroslav Reznik
= Proposed Self Contained Change: Yesod Web Framework =
https://fedoraproject.org/wiki/Changes/YesodWebFramework
Change owner(s): Jens Petersen <petersen(a)redhat.com>, Michel Salim, Ben
Boeckel
Yesod is a Haskell web framework for productive development of type-safe,
RESTful, high performance web applications.
== Detailed description ==
This is a packaging effort: the Yesod stack of packages requires quite a lot of
new Haskell libraries to be added to Fedora. Some basic packages have already
been done for a long time but there are a lot left to be added.
== Scope ==
Proposal owners: Yesod stack of libraries will be packaged following package
versions in latest yesod-platform (currently 1.2.2):
* Package yesod-core and its dependencies
* Package yesod and its dependencies
Other developers: N/A (not a System Wide Change)
Release engineering: N/A (not a System Wide Change)
Policies and guidelines: N/A (not a System Wide Change)
10 years, 9 months