devel-announce January 2013

devel-announce@lists.fedoraproject.org

9 participants
100 discussions

Proposed F19 Feature: Checkpoint/Restore
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/Checkpoint Restore = https://fedoraproject.org/wiki/Features/Checkpoint_Restore Feature owner(s): Adrian Reber <adrian(a)lisas.de> Add support to checkpoint and restore processes. Checkpointing processes can be used for fault tolerance and/or load balancing. Checkpointing a process in regular intervals can help to restart a process if it might crash to resume/restart/restore the calculation without too much data lost. Providing this ability transparent at the OS level removes the need to implement this functionality for all processes manually. Checkpointing and restoring a process to another system can be used to migrate a process, process tree or container to another system to distribute the load during the runtime and also for maintenance without service interruption like it is possible with virtual machines. == Detailed description == Checkpointing/restore, as mentioned above, can be used for fault tolerance and load distribution. Fedora can offer checkpoint/restore by using CRIU (Checkpoint/Restore In Userspace). CRIU has been developed with the goal to be accepted by upstream and most patches necessary have already been accepted (as of 2012-10-24) in the kernel. The current release (0.3) of the userspace tools (crtools) offers the ability to checkpoint/restore containers and thus offering the ability to migrate containers. To offer the checkpoint/restore functionality the package crtools has been imported into Fedora and changes are still necessary to the kernel RPM.

1 0

Proposed F19 Feature: Syslinux Option
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/SyslinuxOption = https://fedoraproject.org/wiki/Features/SyslinuxOption Feature owner(s): Matthew Miller <mattdm(a)fedoraproject.org> This feature will make Syslinux an optional bootloader for Fedora, in kickstart and via a hidden Anaconda option. When used this way, it will replace grub2. == Detailed description == The Syslinux bootloader has been part of Fedora for over a decade. It's been well-tested as the loader for the installer, but we've always used something else on the installed OS. Newer versions of Syslinux (in the form of a version called Extlinux) can boot from ext2/3/4 or from btrfs.

1 0

Proposed F19 Feature: OpenStack Grizzly
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/OpenStack Grizzly = https://fedoraproject.org/wiki/Features/OpenStack_Grizzly Feature owner(s): Pádraig Brady <pbrady(a)redhat.com> OpenStack will be upgraded to the next major stable release, called "Grizzly". In addition the new OpenStack "heat" and "ceilometer" incubation projects will be included. == Detailed description == OpenStack is an open source cloud computing platform. It lets you set up your own cloud infrastructure, similar to public clouds like Amazon EC2, Azure, etc. In Fedora 18 OpenStack Folsom was packaged and in Fedora 19 we aim to package OpenStack "Grizzly", including both incubation projects "heat" and "ceilometer" Grizzly is not released yet, but is scheduled to be released roughly over the same development period as Fedora 19, and we are working closely with upstream to ensure this happens.

1 0

Proposed F19 Feature: Scratch for Fedora
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/Scratch = https://fedoraproject.org/wiki/Features/Scratch Feature owner(s): Matthew Miller <mattdm at fedoraproject dot org> Scratch is an educational programming environment which makes it easy to create games, animations, and art. It's open source and would be a great addition to Fedora. == Detailed description == Read more about Scratch at http://scratch.mit.edu. Previous versions were not open source, but this one is. We've also worked with upstream to resolve issues around licensing and proprietary media formats.

1 0

Proposed F19 Feature: Fedora Upgrade - using yum
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/FedoraUpgrade = https://fedoraproject.org/wiki/Features/FedoraUpgrade Feature owner(s): Miroslav Suchý <msuchy(a)redhat.com> Upgrade Fedora to next version using yum upgrade. == Detailed description == In past (until Fedora 17) we could upgrade Fedora using Anaconda Upgrade and PreUpgrade. Now (in Fedora 18) we have only FedUp and previous methods are obsoleted. I propose to have FedUp and FedoraUpgrade in Fedora 19. FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line upgrade). Some devels say that offline upgrade is only way. But on-line upgrade is possible. E.g in Debian world it is even prefered method. In Fedora exist upgrade using yum as unofficial method for long time. A lot of people are using upgrade using yum for long time and the "problem ratio" was at least on pair with Anaconda upgrade. In fact most problems comes from improper packaging. E.g. maintainer forgot to obsolete, so during upgrade user get file conflict. Once these problems are reported and fixed the upgrade is without problem. And since FedUp is just different approach to yum-upgrade, FedUp will benefit from fixes on FedoraUpgrade (and vice versa). I propose to support both FedUp and FedoraUpgrade and give user option. If this method will be tested by FedoraQA, then I believe this upgrade method can be safely recommended to user.

1 0

Proposed F19 Feature: First-Class Cloud Images
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/FirstClassCloudImages = https://fedoraproject.org/wiki/Features/FirstClassCloudImages Feature owner(s): Matthew Miller <mattdm at fedoraproject dot org> This feature expands Fedora's current cloud image deliverables beyond just EC2, and overhauls how they are produced. The goal is to produce cloud images for EC2 and other cloud deployments for the Alpha, Beta, and Final compose process and distribute them on the mirror network. There will also be nightly or weekly image builds for Rawhide to assist with early development. All images should be constructed using a newer generation of tools. == Detailed description == * New images that can be used in other cloud deployments (such as OpenStack, CloudStack, or Eucalyptus) will be produced. They will be in a qcow2 format and lack the EC2-specific customization. Images for this feature would ideally work for all cloud deployments and there will be i686 and x86_64 versions of both image types. In total and "image drop" will have 4 images: 2 arches for 2 different types (EC2, not-EC2). * An image drop will be produced for Alpha, Beta, and Final composes for Fedora 19 and forward. * Scratch build image drops will be produced on a weekly basis for Fedora 19. * Scratch build image drops will be produced on a weekly basis for Rawhide as well to enable early testing. * The Fedora Koji instance needs to be updated to a future release that will integrate with ImageFactory and Oz from the Aeolus Project. This future release is not implemented yet. * The EC2 images will be automatically uploaded and registered in EC2. The Final AMIs for Fedora 19 will be available in the Amazon marketplace.

1 0

Proposed F19 Feature: SSSD improve AD integration
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/SSSDImproveADIntegration = https://fedoraproject.org/wiki/Features/SSSDImproveADIntegration Feature owner(s): Jakub Hrozek <jhrozek(a)redhat.com>, Sumit Bose <sbose(a)redhat.com> The next major release of SSSD will include support for more advanced AD features for domain members. This includes site support and trusted domains. Additionally it will include a plugin for the cifs-utils package which would allow a CIFS client to use SSSD for lookups which were currently only possible with winbind. == Detailed description == So far SSSD development of AD provider concentrated on doing the user and group lookups for the joined domain efficiently with high performance. With the next major release of SSSD support for some features which are specific to AD domain will be added. This includes: * Site support: AD domains which include different physical locations can be split into sites. Each site represents a single physical location. With specially crafted DNS service record lookups an AD client can find the nearest domain controller, i.e. the domain controller in its site. This helps to keep network traffic local and allows clients to talk to the server with the lowest latency. * Trusted domains: currently the SSSD AD provider can only look up user and groups of the joined domain. With the support of Global Catalogs all users and groups of the forest the AD domain belongs to are available. Additionally it is planned to follow cross forest trust to look up users and groups in trusted forests. * CIFS client integration: in version 5.9 of the cifs-utils a plugin interface for ID mapping was added. This allows cifs-utils to use other services than winbind for those lookups. While those lookups are not needed for basic operation, i.e. accessing files from a Linux client on a Windows/Samba file server, they are needed e.g. when accessing and modifying access control lists (ACLs).

1 0

Proposed F19 Feature: Ns3 network simulator
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/Ns3 = https://fedoraproject.org/wiki/Features/Ns3 Feature owner(s): Vedran Miletić <rivanvx at gmail dot com> Design packaging scheme for ns-3 network simulator and provide it in Fedora. == Detailed description == "ns-3 is a discrete-event network simulator for Internet systems, targeted primarily for research and educational use. ns-3 is free software, licensed under the GNU GPLv2 license, and is publicly available for research, development, and use. ns-3 is intended as an eventual replacement for the popular ns-2 simulator." (ns-3 home page) For now, we package ns-3.16 with some extra patches which will eventually be upstreamed (hopefully, at least). Pretty usable spec file (both C++ and Python simulations work) for ns-3 version 3.16 is available at that bug report along with required patches. Still missing: visualizer (TODO, should be easy), click (TODO, should be a bit of work but not too hard), openflow (might consider it when/if Blake Hurd's changes go upstream, see below for details).

1 0

Proposed F19 Feature: Ryu - Network Operating System
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/Ryu = https://fedoraproject.org/wiki/Features/Ryu Feature owner(s): Isaku Yamahata <yamahata at private.email.ne.jp> Ryu Network Operating System http://www.osrg.net/ryu/ == Detailed description == Ryu is an Operating System for Software Defined Networking. Ryu aims to provide a logically centralized control and well defined API that make it easy for operators to create new network management and control applications. Currently, Ryu manages network devices by using OpenFlow. You can say that Ryu is an OpenFlow Controller. For Software Defined Networking or OpenFlow, please refer to Open Networking Foundation [1]. [1] https://www.opennetworking.org/

1 0

Proposed F19 Feature: KScreen - KDE screen management
by Jaroslav Reznik 23 Jan '13

23 Jan '13

= Features/KScreen = https://fedoraproject.org/wiki/Features/KScreen Feature owner(s): Dan Vrátil <dvratil(a)redhat.com> Replace current KDE screen management software by KScreen. == Detailed description == KScreen is a KDE screen management software that massively improves user experience when working with multiple monitors in KDE. It provides modern user interface and can automatically save and restore screen configuration profiles. It obsoletes the current screen management software.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce January 2013