[PATCH] - catch stdout/stderr from the power commands
by Bill Peck
We have been experiencing some problems with the fence scripts,
Currently you need to run cobbler system power commands from the cmdline
to see the errors. The following patch records the stdout/stderr in
cobblerd.log and returns it to xmlrpc calls.
Its also committed to my public cobbler git repo here:
http://fedorapeople.org/gitweb?p=bpeck/public_git/cobbler.git;a=commit;h=...
>From 0d5b13e8cb38ddf9cf8b1b0c1bda24ffc0fa7321 Mon Sep 17 00:00:00 2001
From: Bill Peck <bpeck(a)redhat.com>
Date: Wed, 3 Jun 2009 14:52:21 -0400
Subject: [PATCH] catch stdout/stderr from running power commands and report them back
---
cobbler/action_power.py | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/cobbler/action_power.py b/cobbler/action_power.py
index 3d62956..8586463 100644
--- a/cobbler/action_power.py
+++ b/cobbler/action_power.py
@@ -29,6 +29,7 @@ Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
import os
import os.path
import sub_process
+from sub_process import PIPE
import sys
import traceback
import time
@@ -126,13 +127,16 @@ class PowerTool:
# Some power switches are flakey
for x in range(0,5):
rc = sub_process.call(cmd, shell=False, close_fds=True)
+ handle = sub_process.Popen(cmd, stdout=PIPE, stderr=PIPE,
+ shell=False, close_fds=True)
+ rc = handle.wait()
if rc == 0:
break
else:
time.sleep(2)
if not rc == 0:
- raise CX("command failed (rc=%s), please validate the physical setup and cobbler config" % rc)
+ raise CX("command failed (rc=%s), %s please validate the physical setup and cobbler config" % (rc, handle.communicate()))
return rc
--
1.6.0.6
14 years, 11 months
Feature request in reference to (Standard comment blocks for snippets)
by Christopher Dale
Michael -
The comments feature certainly will be much appreciated especially if the
Requirements section lists all of the variables that must be defined for the
kickstart to be generated. As an additional feature, would it be possible
to get something like cobbler system uservars --system=bob. This would be
different from dumpvars in that it would list the user defined variables
from the template that 'should' have been set in a profile, sub-profile or
system. So, say that I have forgotten to define a variable and my getks
command produces something undesireable, You would be able to quickly check
if you set all of your variables (or at least spelled them consistantlly)?
Thanks in advance,
Christopher
14 years, 11 months
Re: Storage provisioning with cobbler
by Christopher Dale
Michael, Scott and Owen -
First of all, I hope that it is not inappropriate for me to comment on
this list when I am not involved with the development of cobbler.
Having been involved with infrastructure for the last 20 years, I would
like to see the storage handle with a 'pool' type approach. By that I mean
that I would like to be able to assign 15G of storage to a VM from the
'fast' pool or the 'secret' pool of the 'archive' pool or the 'working' pool
(pool names should be named and defined kind of like a server profile.
Having worked with HP, EMC, StorageTek and 3PAR SAN, I can say that the
graphical means of configuring these SANs can be wildly different. But,
being able to issue a command like 'cobbler pool add --name=archive
--model=tserv ..... would be extremely helpful, although, I realize that
that is a daunting task. Have you thought about engaging the vendors?
I think that the handling of the FC switching would need to be handled
separately (based on vendor and model). The cobbler administrator would
need to know something about this technology, but the cobbler user who is
creating system definitions could propably remain unaware of the details.
The way that I think of cobbler in the future is as a tool that let's me
(as a template creator) not have to know the things that I (as a hardware
tech) have to know. In this way, it would be nice to one day type commands
like these:
cobbler san add --name=bob (and what ever else needs to be provided to allow
cobbler to create LUNs)
cobbler eswich add --name=ethswith01 (and what ever else needs to be
provided to allow cobbler to manage the elements of that switch)
cobbler fsswitch add --name=fcswitch01 (...)
cobbler server name --id=(this would be the id that is returned when you
have booted the server for the first time and its capabilities have been
collected) --name=
cobbler system (maybe service) add --name=example
--processing-group=production --processing-group-units=2
--storage-pool=development --storage-size=15G --networks= ...
Too out there to be relevant today, I kow. But, would be interested in
hearing what views others have for the distant future.
Thanks to those that read the entire post
Christopher (irc: Commoner)
14 years, 11 months
New snippet for adding a bootloader reinstall entry for classrooms/labs
by Michael DeHaan
Koan has had a feature for a while that allows for adding an entry to
grub to reinstall the system -- without making it the default option.
koan --replace-self ---server=cobbler.example.org --add-reinstall-entry
This can be useful for lab/classroom setups where a machine may need to
be installed due to being otherwise screwed up, and there is not a
security concern
of needing to restrict access to that option (though I suppose folks
could also configure a grub password if needed). For instance, a
classroom machine in a training
scenario may want to be reinstalled at any time, and the kickstart on
that system may be set up to put it back in a working state -- the data
on the system is likely
completely unimportant. The same goes for "kiosk" type systems and
things that folks are just using for anonymous web access. Perhaps
Cobbler-powered cyber cafes
if you will.
The instructions for this are here (below), and because I think we
should make that easier, I've made it a snippet for 2.0
https://fedorahosted.org/cobbler/wiki/KoanDoesReinstall
Right now it's not included in the default snippets by default, though
if we're following the func example, it should be, and should have a
setting to turn it on/off.
Thoughts? I'd like to be consistent one way or the other, I think.
I'm not sure why that inconsistency bothers me, but at the same time, I
want to keep settings
reasonably short, where it's already starting to grow a bit.
--Michael
14 years, 11 months
Task engine, background tasks, and the web application-- some planning
by Michael DeHaan
Goal: Let the web app do /EVERYTHING/ the CLI can do (or almost
everything)
Currently there are some operations which can't be run by the remote
XMLRPC API, and because of this, can't be run in the web app.
These are the long running operations.
Currently we let sync be done in the web app, but this is also one of
those potentially long-running operations.
What I want to do is implement a task engine in cobblerd.
We have various logic for this we can pull off the shelf, most likely
Func's async implementation of virt-factory's taskatron will serve as a
reference.
Then we list a page on the web app that shows the names of all running
tasks and their status.
When a sync is initiated, for instance, the output would be viewable
from the web app.
Cobbler should be happy with concurrent operations given that we have
fine grained locking around access to the datastore
(/var/lib/cobbler/config) so things
should only block when needing to update cobbler configuration objects.
Output from operations can go to /var/log/cobbler/tasks/$taskid.log and
cobblerd can take care of removing task logs for tasks that are, say, X
days old.
Technically this should also allow kicking off the same long running
tasks from either the Python API or XMLRPC API. We'll keep the
existing APIs
for backwards compat... the new ones will return taskids that can be
queried with something like:
get_task_status(task_id) -> (status, logfile) and get_task_log(logfile)
I suspect sync for instance might look like reposync takes a new
parameter, default being "background=False". The backgrounding mode would
return the task ID instead of the results.
We would also want to add the ability to list running tasks from the
command line.
Some tasks, like reposync, allow the ability to sync only certain repos,
so this seems to imply that we would want to expose that in the GUI by
adding a "sync" button on
the repo list page, as well as a "reposync" button below the sync page.
Other items like "buildiso" would also get actions, set to output to
public directories in /var/www/html somewhere that we could easily link to.
Cobbler check data, while not time consuming and needing background
queing, should also be visible in the web app.
The new "deploy" API bits should most definitely be exposed, probably
with those requiring a new page for user input.
--Michael
14 years, 11 months
Network objects for 2.0 -- anyone want to help with these?
by Michael DeHaan
Assuming we wanted to get 2.0 in a state to release in 1.5 months,
anyone interested in woring on the network objects support?
I /could/ do this, but I think it's one of those atomic chunks that may
make a good thing for someone else to work on ... plus it's pretty close
to being stubbed out.
I think a good place to start is looking over item_network.py and seeing
what fields it has, and what fields it /needs/ to have. Then because
of the field storage changes,
the way it keeps the free list of IPs around needs to be implemented
such that it works again.
(Some steps in the middle I'm sure -- one of the catches is what happens
when we delete a network -- is that even legal if systems are attached?
Probably no, and coming up with a way
to remove a system from a network with the edit command --network="" or
some equivalent, and having the IPs then no longer be pulled from there)
Finally we need to tweak the utils.blender code so that objects with a
network assigned fill the variables from the network.
Similarly on the system edit page of the webapp, if an interface belongs
to a network those fields should be hidden that are sourced from the
network or otherwise populated from the network. TBD.
For those that don't grok what I'm talking about, suppose we define the
following IP setup:
cobbler network add --name=foo --cidr=<range1> --gateway=<ip>
--broadcast=<ip> ...
cobbler network add --name=foo --cidr=<range2> --gateway=<ip>
--broadcast=<ip> ...
cobbler system add --name=bar --network=foo --interface=eth0
--network=foo --mac=AA:BB:CC:DD:EE:FF --dns-name="bar.example.org"
cobbler system edit --name=bar --network=foo --interface=eth1
--network=bar --mac=AA:BB:CC:DD:EE:FE --dns-name="bar.lab.example.org"
cobbler system add --name=baz --network=foo --mac=AA:BB:CC:DD:EE:FD
--dns-name="baz.example.org"
If you notice in the above case, we didn't bother to assign IPs to any
of the systems, yet we were able to assign hostnames directly, because
the network object assigns IPs for us.
There are other applications, such as being able to assign the DHCP/DNS
generator for certain servers to only do it for certain networks, for
instance we could centrally manage everything for an organization at a
central point but a regional/datacenter cobbler server could know to
only template out DHCP/DNS for those systems that were local to it (as
configured in settings). This would also mean we could tell cobbler
replicate to not pull down systems for "foreign" networks.
I could also see a way to flag the network as static, so we wouldn't
have to specify each network as static, and do some nice things there as
well.
If there are no takers I'll probably start looking into this, but even
then some help would be great -- also if you have any additional ideas
about network objects and how they might be able to help you out, let us
know.
--Michael
14 years, 11 months
Django progress, web/CLI, object-upgradeablility testing needed for devel branch
by Michael DeHaan
The web app now presents error pages for edits again, validates objects
for being consistent before saving them (not just the web app), we have
batch editing working, and misc. cosmetic improvements (uppercase in a
few areas). Subprofiles should work better. Lots of random things.
I think it's mostly usable, though there are a few forms that should
still end up on the error pages, rather than showing the Django debug
pages, but not too many.
I also suspect the "check_if_valid" code needs a bit of enhancement, and
we need to pound on things pretty hard to see what breaks.
Anyway, please test away, and why you are doing so, make a note of
anything that just looks broken/unfinished when compared with the old
webapp.
I know of a few such items -- the way the DIVs dump text below the
navigation half of the time is certaintly one of these.
I'd also try to break the interface editor, or any of the editors, and
see what works/doesn't ...
The CLI could probably use equivalent bashing, I know --in-place doesn't
currently work, there are probably a few other options that don't work
since the refactoring.
It would be best if testing could be done against an old copy of the
cobbler objects (like your production copy), but obviously don't run
devel against production -- it may very well clobber your configs. But
making sure the data is preserved across the upgrade here is pretty
important, so feeding it old data would be useful.
I'm going to be doing more testing myself of course in the next week,
but the idea now is to get what we have back to "Cobbler 1.6.5 feature
equivalence" state, running off the new codebase, before adding anything
new.
Thanks!
--Michael
14 years, 11 months
It's a small codebase after all
by Michael DeHaan
We're shrinking. This is a good thing. Plenty of releases have added
features to Cobbler, 2.0 gives us a chance to /remove/ code while
keeping those features intact.
By throwing out a ton of code for manually updating the CLI and web app,
the whole stack is now a lot smaller than it used to be.
SLOC Directory SLOC-by-Language (Sorted)
13046 cobbler python=13046
3050 koan python=3050
805 web python=805
328 scripts python=328
One of the main reasons for the cleanup in the webapp was that folks no
longer have to know how to work on the web app, or the command line, to
add fields to cobbler -- which means editing /many/ less
files than folks used to have to edit. I think this is going to be
pretty huge moving down the road.
(That all being said, we do need to make sure that the new tables we've
added that populate the CLI, web app, and data model are sufficiently
well documented -- and a "how to add new fields to cobbler"
article on the Wiki cannot hurt -- I'm keeping this in mind for when we
start some Wiki cleanup)
--Michael
14 years, 11 months
Cobbler 2.0 CLI working now for all options (hopefully) / multiple interface editing is a new feature
by Michael DeHaan
The CLI should now be fully working again, with the addition of the
fields that were present in previous implementations (--clobber,
--in-place, --interface, --delete-interface) that weren't directly related
to being normal data elements. Given this, I would say that Cobbler
2.0 (head of master branch in git) probably doesn't eat babies now, but
it might. Use caution, but I think it's mostly functional.
I made one small improvement for batch editing interfaces:
The following now works:
cobbler system edit --name=foo --static=1 --interface="eth0 eth1"
And also you can do multiple interface deletions in one command.
cobbler system edit --name=foo --delete-interfaces="eth2 eth3"
Basically before you had to edit one and a time.
(Note that XMLRPC and the Python API still requires multiple API
calls, this is only command line stuff)
I also discovered optparse does option validation, so we now get a bit
nicer error messsages when you specify the wrong value for something
that takes a choice of options:
[mdehaan@mdehaan cobbler]$ sudo cobbler system edit --name=p --bonding=blip
Usage: cobbler system edit [ARGS]
cobbler: error: option --bonding: invalid choice: 'blip' (choose
from 'na', 'master', 'slave')
Optparse will actually do type validation, but because of internals of
how we store inherited values (like it or not), we can't use them.
This would mean there would be no way to set a value back
to "<<inherit>>" for some fields, and while I don't think people should
need to know what <<inherit>> means that's a niche use case that should
still be supported just in case it's important for someone
to undo what they did in a profile somewhere. If you clear a field to
"" that means "space", not "use what's defined in the parent object", so
that's not quite the same thing.
If folks can find a way to teach getopt to allow multiple options, such
as the following, we'll take it, but you still can't do:
"cobbler system edit --name=foo --interface=eth0 --foo=bar
--interface=eth1 --foo=baz"
Which doesn't really bother me too much. Anyway, I like being able to
adjust fields on all interfaces (or more than one) when needed...
It does look like we have to reinstate duplicate MAC/hostname
prevention, however, which apparently does /not/ work on 2.0 because
we've done some cleanup. I think this was previously enforced by the
older validation logic in each item_*.py class, so I'm going to take a
look at that. (If so, it will be trivial to reinstate).
--Michael
14 years, 11 months
[PATCH] Add alternate option support, to remap things like kernel_options to --kopts
by James Cammarata
Took advantage of the field_info stuff to add a new mapping hash:
ALTERNATE_OPTIONS. So far, I've only added ksmeta, kopts, and kopts-post
to it, so there are probably some more modified versions to go in. I also
fixed up the indentation in the add_options_from_fields() function since
some lines were only indented 3 spaces (trying to be consistent about that
now...)
commit f5f037ff224d74cd3818a9886065d54ca153fc38
Author: James Cammarata <jimi(a)sngx.net>
Date: Sun May 31 17:22:19 2009 -0500
Add alternate option support, to remap things like kernel_options to
--kopts
Fix indentation in add_options_from_fields()
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
14 years, 11 months