devel-announce January 2013

devel-announce@lists.fedoraproject.org

9 participants
100 discussions

Proposed F19 Feature: Thermostat 1.0
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/Thermostat1.0 = https://fedoraproject.org/wiki/Features/Thermostat1.0 Feature owner(s): Omair Majid <omajid(a)redhat.com> == Detailed description == Thermostat is a serviceability and instrumentation tool for OpenJDK. The 1.0 release of thermostat brings a number of new features that developers may find very useful. * More information for Hosts and Java Virtual Machines being monitored * A stable API for external plugin developers * Ability to use thermostat, securely, in a network or a cluster * An experimental eclipse plugin that lets developers use eclipse as a thermostat GUI The goal is to get the 1.0 release of thermostat into Fedora 19. If upstream also releases 1.1 before the alpha deadline for Fedora 19, we may use that instead.

1 0

Proposed F19 Feature: Network Team driver - Update for new features
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/TeamDriverUpdate = https://fedoraproject.org/wiki/Features/TeamDriverUpdate Feature owner(s): Jiri Pirko <jiri(a)pirko.cz> Network Team driver allows multiple network interfaces to be teamed together and act like a single one. This update adds several kind of new features to it. == Detailed description == The goal is to extend current Team driver experience in Fedora. In order to do that, following features will be implemented: * ARP link validation over VLAN * Transmit hashing involving L4 headers * Support for NICs which do now allow mac change on run * Load balancing support for incoming traffic * Corrected carrier detection

1 0

Proposed F19 Feature: Systemtap 2.2
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/Systemtap22 = https://fedoraproject.org/wiki/Features/Systemtap22 Feature owner(s): Lukas Berk <lberk(a)redhat.com>, Frank Ch. Eigler <fche(a)redhat.com> A new feature release of Systemtap. == Detailed description == Systemtap 2.2 will introduce several new features: * Native Java per-method probing capabilities (using byteman) Plus new features coming from the impending systemtap 2.1: * A suite of error-explanation man pages. * Perf event probes may now be read on demand * Perf event probes may now be bound to a specific task using the process name * The dyninst backend's runtime has been improved to allow much more concurrency when probing multi-threaded processes

1 0

Proposed F19 Feature: Realmd FreeIPA Support
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/RealmdFreeIpaSupport = https://fedoraproject.org/wiki/Features/RealmdFreeIpaSupport Feature owner(s): Stef Walter <stefw(a)redhat.com> realmd currently supports discovery and configuring of Active Directory domains. With this feature it will also include support for FreeIPA domains. == Detailed description == realmd is an on demand system DBus service, which allows callers to configure network authentication and domain membership in a standard way. realmd discovers information about the domain or realm automatically and does not require complicated configuration in order to join a domain or realm. realmd will be able to be used with FreeIPA. Current GUI and CLI tools that use realmd to join Active Directory domains will now be able to seamlessly join FreeIPA domains as well.

1 0

Proposed F19 Feature: Pcsd Configuration Wizards
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/Pcsd Configuration Wizards = https://fedoraproject.org/wiki/Features/Pcsd_Configuration_Wizards Feature owner(s): Chris Feist <cfeist(a)redhat.com> This feature will allow easier building of configuration wizards for pcsd (the Pacemaker/Corosync GUI), so through a simple configuration file we can create wizards for some common configurations (such as setting up a 2 nodes HA webserver). == Detailed description == The new feature will allow for a configuration file to be used to create wizards (instead of manually creating javascript/html, etc.) for each separate wizard. Initially the simple configuration wizards will include the following: * 2 node HA webserver

1 0

Proposed F19 Feature: oVirt engine 3.2
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/oVirtEngine 3.2 = https://fedoraproject.org/wiki/Features/oVirtEngine_3.2 Feature owner(s): Juan Hernández <juan.hernandez(a)redhat.com> The oVirt engine is the management application of the oVirt virtualization platform. Version 3.2 is the latest version, including many new features. == Detailed description == Version 3.1 of the oVirt engine was already included in Fedora 18, but we want to bring the new features provided by version 3.2. The version 3.2 of the oVirt engine includes the web based user interface for administrators and users, and many new features, for example: * UI plugins * Make network a main tab * Import of existing gluster clusters * Bootstrap improvements * PKI improvments * MOM * Improved quota * Integrate smartcard support * Display address override * VM creation base on pre-defined profiles (instance types) * Storage live migration (needs to be checked) * Sync network * Port mirroring * User level api * Automatic storage domain upgrade * Unidirectional Gluster geo-replication support * Support for asynchronous Gluster volume tasks * Gluster volume performance statistics * Configuration sync with Gluster CLI * Monitoring Gluster Volumes and Bricks

1 0

Proposed F19 Feature: NetworkManager Bridging Support
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/NetworkManagerBridging = https://fedoraproject.org/wiki/Features/NetworkManagerBridging Feature owner(s): Pavel Šimerda <psimerda at redhat.com>, Dan Williams <dcbw at redhat dot com> NetworkManager should be able to configure bridge interfaces with commonly used options and recognize their existing configuration on startup without disrupting their operation. == Detailed description == A bridge connects two or more physical or virtual network interfaces to allow network traffic to flow between the two interfaces at a low level. Bridging is commonly used to connect Virtual Machines to the outside world; a bridge interface is created, to which a physical interface (typically ethernet) is assigned as a slave, and a virtual interface (typically TAP) is created and also assigned to the bridge as a slave, and then given to the Virtual Machine. Thus traffic from one or more VMs can be combined and sent out of the machine via the physical interface. This setup is currently done either manually using ifcfg files and ifup/ifdown, or by a tool like libvirt/netcf. NetworkManager should be able to configure bridge interfaces and their slaves with the same functionality as provided by libvirt, and should recognize and not disrupt existing bridge connections when it starts up.

1 0

Proposed F19 Feature: NetworkManager Bonding Support
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/NetworkManagerBonding = https://fedoraproject.org/wiki/Features/NetworkManagerBonding Feature owner(s): Pavel Šimerda <psimerda at redhat.com>, Dan Williams <dcbw at redhat dot com> NetworkManager should be able to configure bond master interfaces with commonly used options and recognize their existing configuration on startup without disrupting their operation. == Detailed description == NetworkManager's existing support for bond interfaces covers a limited number of use-cases and can conflict with existing bonding configurations created by tools like libvirt. The purpose of this Fedora feature is to implement more flexible bonding infrastructure in NetworkManager to support an expanded number of use-cases and to be more cooperative with other users of bonding. Support will be added to NetworkManager to detect the existing configuration of a bond interface and its slaves and to seamless "take over" that connection without disrupting it. Even if the existing configuration is not backed by ifcfg files on-disk, NetworkManager will leave that configuration on the interface unless told to change it by the user via GUI or CLI tools. Additional bond interface configuration will be added to expand the use-cases and hardware that NetworkManager can configure (eg primary, use_carrier, xmit_hash_policy, etc).

1 0

Proposed F19 Feature: firewalld Rich Language
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/FirewalldRichLanguage = https://fedoraproject.org/wiki/Features/FirewalldRichLanguage Feature owner(s): Thomas Woerner <twoerner(a)redhat.com> This feature adds a rich (high level) language to firewalld, that allows to easily create complex firewall rules without the knowledge of iptables syntax. = Detailed Description = Currently, complex firewall rules can only be added using the direct interface of firewalld. But this requires to know the syntax of iptables and the rules are not permanent. With the rich language more complex firewall rules can be created in an easy to understand way. The language will use keywords with (sometimes multiple) values and will be an abstract representation of ip*tables and ebtables rules. Services and zones can be configured using this language, the current configuration will still be supported. A mixture of the old and new configuration of services and zones might be possible, but this needs to be verified. With the possibility to use the rich language in services and zones, the configuration will also be permanent. The configuration with files will be available for Fedora 19. The D-BUS interface with the command line client should be finished, but this depends on Fedora 19 schedule. UI work will most likely be available later (depends on Fedora 19 schedule also).

1 0

Proposed F19 Feature: firewalld Lockdown
by Jaroslav Reznik 30 Jan '13

30 Jan '13

= Features/FirewalldLockdown = https://fedoraproject.org/wiki/Features/FirewalldLockdown Feature owner(s): Thomas Woerner <twoerner(a)redhat.com> This feature adds a simple configuration setting for firewalld to be able to lock down configuration changes from local applications. == Detailed description == Local applications are able to change the firewall configuration. With this feature the administator can lock the firewall configuration and these applications are not able to modify the firewall anymore. The lockdown feature is the first part of user and application policies for firewalld and will be disabled by default.

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