Proposed F19 Feature: OpenShift Origin
by Jaroslav Reznik
= Features/OpenShift_Origin =
https://fedoraproject.org/wiki/Features/OpenShift_Origin
Feature owner(s): Troy Dawson <tdawson(a)redhat.com>
OpenShift Origin is a cloud application platform as a service (PaaS). It is
the open sourced, community supported version of OpenShift.
== Detailed description ==
OpenShift Origin is a cloud application platform as a service (PaaS). It is
the open sourced, community supported version of OpenShift
OpenShift is Red Hat's Cloud Computing Platform as a Service (PaaS) offering.
OpenShift is an application platform in the cloud where application developers
and teams can build, test, deploy, and run their applications.
OpenShift Origin takes care of all the infrastructure, middleware, and
management and allows the developer to focus on what they do best: designing
and coding applications.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 4 months
Re: Strange subscriptions to Bugzilla bugs
by Patrick Monnerat
rutadeevacuacion continues its crazy job: (s)he's just subscribed to one
of my review request (closed 2009-08-07) BZ#505356.
Although this does not affect me personally, I think this is some
obscure way of mass parasitizing our infrastructure. No way to blacklist
this address ?
11 years, 4 months
Proposed F19 Feature: Ease Of Use: System Management with OpenLMI
by Jaroslav Reznik
= Features/OpenLMIEaseOfUse =
https://fedoraproject.org/wiki/Features/OpenLMIEaseOfUse
Feature owner(s): Tomáš Smetana <tsmetana at redhat.com >
Add providers and capabilites to the OpenLMI infrastructure that would ease
the remote system management.
== Detailed description ==
The OpenLMI project provides a common infrastructure for the management of
Linux systems. The goal is to add the missing parts that would enable remote
management of a Fedora system:
* Complete the CIM storage API to allow for a better remote storage management
* Add a new provider and extend the existing ones to allow for a remote
hardware information retrieval (HW inventory)
* Add a new provider that would allow for a remote AD/Kerberos realms
enrollment
* Add a new provider that would allow for a remote Firewall management
(open/close a particular port) through firewalld
* Improve the software management in OpenLMI to allow for a comprehensive
remote package management
* Add and improve the remote system monitoring using OpenLMI
* Improve the OpenLMI Shell to allow for a quick and easy scriptable remote
management
* Allow to use OpenLMI under selinux enforcing policy
* Possibly add providers to allow management also other system parts:
Containers, SELinux, SCAP scans, performance monitoring
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 4 months
abrt server report: 20130129
by Michal Toman
Hot problems:
ID Components Count
-------------------------------------------------------
185766 kernel 1294
204154 kernel 1198
85820 yumex 786
100106 gnome-packagekit 754
221206 kernel 741
258569 kernel 690
20295 gnome-shell 669
57483 blueman 579
83012 tracker 555
273202 rhythmbox 543
URL: https://retrace.fedoraproject.org/faf/problems/hot/
Long-term problems:
ID Components Count
-------------------------------------------------------
275755 kernel 3301
58474 kernel 2408
100106 gnome-packagekit 2012
83012 tracker 1825
20085 gnome-terminal 1362
19369 control-center 1317
117749 gnome-packagekit 1078
274020 kernel 990
20171 gnome-shell 977
85820 yumex 917
URL: https://retrace.fedoraproject.org/faf/problems/longterm/
Most destabilized components:
Component Jump Graph
----------------------------------------------------------
kernel 783 ▁▅▃▂▆▃█
gvfs 34 ▁▁▁▃█▇▅
gnome-shell 76 ▂▂▁▂▁▁█
blueman 8 ▄▁▃▄▅█▆
evolution 34 ▁▄▁▅▁▁█
Most stabilized components:
Component Jump Graph
----------------------------------------------------------
gnome-settings-daemon -22 ▄█▆▄▁▁▁
dconf -29 █▅▆▁▁▁▁
gnome-terminal -22 █▆▃▁▁▁▂
libreoffice -16 █▆▅▂▃▁▄
setroubleshoot -16 ▆▆█▅▄▂▁
Server URL: https://retrace.fedoraproject.org/faf/
Report a bug: https://fedorahosted.org/abrt/newticket?component=faf
Server sources: http://git.fedorahosted.org/cgit/faf.git/
11 years, 4 months
Proposed F19 Feature: Multiqueue virtio-net
by Jaroslav Reznik
= Features/MQ virtio net =
https://fedoraproject.org/wiki/Features/MQ_virtio_net
Feature owner(s): Jason Wang <jasowang(a)redhat.com>
Multiqueue virtio-net provides an approach that scales the network performance
as the increasing of the number of vcpus by allowing them to transfer packets
through more than one virtqueue pairs.
== Detailed description ==
Today's high-end server have more processors, guests running on them tend have
an increasing number of vcpus. The scale of the protocol stack in guest in
restricted because of the single queue virtio-net:
* The network performance does not scale as the number of vcpus increasing:
Guest can not transmit or retrieve packets in parallel as virtio-net have only
one TX and RX, virtio-net drivers must be synchronized before sending and
receiving packets. Even through there's software technology to spread the
loads into different processor such as RFS, such kind of method is only for
transmission and is really expensive in guest as they depends on IPI which may
brings extra overhead in virtualized environment.
* Multiqueue nic were more common used and is well supported by linux kernel,
but current virtual nic can not utilize the multi queue support: the tap and
virtio-net backend must serialize the co-current transmission/receiving
request comes from different cpus.
In order the remove those bottlenecks, we must allow the paralleled packet
processing by introducing multi queue support for both back-end and guest
drivers. Ideally, we may let the packet handing be done by processors in
parallel without interleaving and scale the network performance as the number
of vcpus increasing.
The following parts were changed to parallize the packet processing:
* tuntap: convert the driver to multiqueue by allowing multiple socket/fd to
be attached to the device, each socket/fd exposed by the device could be
treated as a queue.
* qemu:
* net: Add multiple queue infrastructure to qemu
* let qemu can create multiple vhost threads for a virtio-net device
* userspace multiple queue virtio-net
* guest driver: let the driver can use multiple virtqueues to do packet
sending/receiving.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 4 months
IDLE state:High CPU utilization
by magina antimage
Hi,
I have ported fedora for my target board,
i am getting high CPU utilisation(30-35%) even when my system is idle
(no gnome / X session).
i used top command to see which process is consuming CPU,but couldn't find
any.
any help.
Thanks
11 years, 4 months
Proposed F19 Feature: Better NetworkManager IPSec Integration
by Jaroslav Reznik
= Features/BetterNetworkManagerIPSecIntegration =
https://fedoraproject.org/wiki/Features/BetterNetworkManagerIPSecIntegration
Feature owner(s): Dan Williams <dcbw at redhat dot com>
IPSec usage is becoming more popular and the existing NetworkManager IPSec VPN
plugin will be enhanced to better support these use-cases and fix known bugs.
== Detailed description ==
The existing VPN plugin uses the openswan IPSec package to provide IPSec
functionality for NetworkManager users. Communication with openswan could be
much more robust and secure by communicating directly with openswan's tools
rather than writing secrets and other configuration out to temporary files like
openswan current requires. Furthermore, NetworkManager should be enhanced to
allow for route-based tunnel connections instead of requiring a TUN/TAP
interface for each VPN connection.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 4 months
Proposed F19 Feature: Anaconda Realm Integration
by Jaroslav Reznik
= Features/AnacondaRealmIntegration =
https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration
Feature owner(s): Vratislav Podzimek <vpodzime(a)redhat.com>, Stef Walter
<stefw(a)redhat.com>
Kickstart will have a 'realm join example.com' command, to join the machine
during install to an AD or FreeIPA domain. This will take place using one time
passwords or password-less joins to an AD or FreeIPA domain.
== 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.
By integrating realmd with Kickstart and Anaconda, administrators will be able
to add machines to a domain en-masse. This can be done without leaking
administrative domain credentials into the kickstart fail.
In addition there will be a GUI for joining a domain during the anaconda
install process.
This will be implemented as an Anaconda addon, to help keep the scope and base
feature set of Anaconda in check.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 4 months
(no subject)
by magina antimage
Hi,
I have ported fedora for my target board,
i am getting high CPU utilisation(30-35%) even when my system is idle
(no gnome / X session).
i used top command to see which process is consuming CPU,but couldn't find
any.
any help.
Thanks
11 years, 4 months
BuildRequires for texlive stuff for F18 and beyond
by Jonathan Underwood
Dear All,
I have various packages that use (La)TeX to generate documentation at
package build time. In the past, this was usually handled fine with a
BuildRequires: tex(latex) which would bring in enough of a latex
environment to build most things.
With the more fine grained texlive packaging in F>18 where tex(latex) is
provided by texlive-collection-latex I am finding that this is insufficient
to build most documents. I see two options in these cases:
1) Add BuildRequires; texlive-collection-latexextra (nb.
texlive-collection-latexrecommended isn't usually sufficient)
2) Generate a list of specific style files using an incantation such as
egrep -R 'usepackage|documentclass|RequirePackage' * | cut -d']' -f2 | cut
-s -d'{' -f 2 | sed s/"}"/.sty"}"/g | cut -d'}' -f1 | sort | uniq
and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
If (1) is the preferred route, then I think we should move the virtual
provides for tex(latex) to the texlive-collection-latexextra package. If
(2) is the preferred route we probably need a wiki page and possibly a
packaging guideline explaining this. I personally lean towards the first
option (i.e. moving the tex(latex) provides to
texlive-collection-latexextra package) as it will fix a lot of packages
that currently will fail to build.
What do folks think?
Cheers,
Jonathan.
11 years, 4 months
