search for: networkdevices

...e.h> #include "host.h" +#include "platform.h" #include "qmf/com/redhat/matahari/Host.h" using namespace qpid::management; @@ -41,6 +42,14 @@ HostAgent::setup(ManagementAgent* agent) // discover the aspects of the host processors.setup(agent, this); + networkdevices = Platform::instance()->get_network_devices(); + + for(vector<NetworkDeviceAgent>::iterator iter = networkdevices.begin(); + iter != networkdevices.end(); + iter++) + { + iter->setup(agent, this); + } struct utsname details; string uuid = "Unkn...

In looking at the code I realized that the last of the HAL depenencies were removed with this patch. So, I'm pushing an updated patch that contains none of the HAL code in it.

...ace _qmf = qmf::com::redhat::matahari; - void -HostAgent::setup(ManagementAgent* agent) +Host::set_uuid(const string uuid) { - management_object = new _qmf::Host(agent, this); - agent->addObject(management_object); - - // discover the aspects of the host - processors.setup(agent, this); - networkdevices = Platform::instance()->get_network_devices(); - - for(vector<NetworkDeviceAgent>::iterator iter = networkdevices.begin(); - iter != networkdevices.end(); - iter++) - { - iter->setup(agent, this); - } + _uuid = uuid; +} - struct utsname details; - string uuid...

I meant to send this out a while back, but don't see that I ever actually sent it. I'm currently reworking the matahari agents to clean up the code, refactor elements and also enhance the agents. And the one that has me stumped is the NIC agent. The main problem is that, if we're going to represent network interfaces, we shouldn't limit it to only physical devices. Instead, I

Refactoring the previous patch ended up creating two deltas. This patch pushes them both together into a single commit.

...diff --git a/src/host.cpp b/src/host.cpp index 29b84ec..6d9a1fe 100644 --- a/src/host.cpp +++ b/src/host.cpp @@ -99,14 +99,19 @@ Host::setup(ManagementAgent* agent, HostAgent* hostAgent) void Host::update() { - _processors.update(); - for(vector<NetworkDeviceAgent>::iterator iter = _networkdevices.begin(); iter != _networkdevices.end(); iter++) { iter->update(); } + + for(set<HostListener*>::iterator iter = _listeners.begin(); + iter != _listeners.end(); + iter++) + { + (*iter)->updated(); + } } void @@ -121,12 +126,6 @@ Ho...

The previous patch, for whatever reason, fails to apply on top of tip. This patch is reimplemented and, hopefully, fixed.

Hello All, I ended up answering my own question, but figured I'd share this and open up for discussion. It is possible to set a metric with 'route' or `ip route`. What I'm wondering is if there's a Red Hat/CentOS way of assigning a metric in the network-scripts? Answer: [0] (from 2008) works. ex: METRIC=10 Deployment Guides: EL5 [1] and EL6 [2] do not mention metrics on

Hello all, Does anyone currently manage Cisco ASA''s out there via Puppet, if so how ? Due to the size of our network it would be great if Puppet could manage Object-groups and ACL''s etc to try and standardize across our ASA hosts. e.g. On one ASA an Object-group would be called monitoring_server on another ASA mon_srv another ASA monsrv It makes understanding the

Hi, I''m using Amazon EC2 and I''m planning to use puppet to deploy automatically my instances, however, I have an issue I can''t rely think through. As most people advised, I used a DNS server (bind to be precise) so that my instances can register to it but also ask this DNS Server the IP of the puppetmaster. However, as this DNS server is also running on Amazon EC2

This introduces support to run P2V without X server. Runtime parameters are specified via kernel command line making it hopefully suitable for automated migration with a little help of PXE boot. Patchset is not squashed and represents dev. history.