Code/documentation conventions
by Alan Evangelista
I noticed Cobbler does not apply some conventions used in other Python
projects. I have some suggestions:
* Validate code using Pylint
* Comment: I think this is fundamental to find subtle errors (eg
referencing inexistent variables). I have already fixed all Pylint
errors I could in my Cobbler clone and I just ignored those few I cannot
fix (eg in templating classes). I could submit relevant patches
upstream. I'll soon automate Pylint checks in any patch submitted by my
team, possibly Cobbler upstream could do the same.
* Introduce documentation convention
* Motivation: makes documentation easier to read and write
* Suggestions:
* Sphinx restructuredText extensions
(http://sphinx-doc.org/domains.html#signatures) .
* simple Javadoc-style documentation convention. eg document methods
are documented with method description, @param <type> <var_name>
<var_description> for each parameter and @return <type>
<return_var_description> for return value. My team uses that and it
works well.
* Comment: I consider param/return type specially useful, as Python
does not declare variable types in method definition.
* Validate code using PEP8 (Python style guide)
* Order imports alphabetically. Possibly, split imports in standard
Python imports, third-party imports and Cobbler imports.
* Motivation: readability
* Remove trailing whitespaces
* Motivation: remove commit noise. I see other reasons at
http://programmers.stackexchange.com/questions/121555/why-is-trailing-whi...
, but imho they are minor.
Maybe some of these suggestions have already been considered in the past
and rejected. If you could share with me these reasons, it'd be much
appreciated.
Regards,
Alan Evangelista
9 years, 11 months
Cobbler CLI: cobbler aclsetup
by Alan Evangelista
Could someone make this command purpose clearer?
Is this command still useful at all?
In cobbler/action_acl.py, I read:
"Configures acls for various users/groups so they can access the cobbler
command
line as non-root. Now that CLI is largely remoted (XMLRPC) this is
largely just
useful for not having to log in (access to shared-secret) file but also
grants
access to hand-edit various config files and other useful things."
Reading this, Cobbler CLI purpose becomes unclear to me. If it is
supposed to be a Cobbler admin-only
tool, it makes sense that is only accessibly by root user in the server.
If it is supposed to be used
by regular users, users should be able to run CLI from anywhere (eg
their local workstations) and the
CLI should connect to remote Cobbler server using XML-RPC interface.
Regards,
Alan Evangelista
9 years, 11 months
Cobbler tests question
by Alan Evangelista
1) Why there are 2 different tests directories (tests and newtests)? Are
there XML-RPC tests in "tests" directory which are not covered in
XML-RPC tests in "newtests" directory?
I'd like to merge those.
2) What's the benefit in numbering tests? It seems to me it only
introduces overhead of renaming tests when one is deleted (if we want to
avoid numbering gaps).
3) CLI import tests access a /vagrant directory which I obviously
developers will not have in their local workstations.
Is there a test server we could use to test that? Otherwise, it should
be upstream?
4) CLI tests only check return code. Should they not test at least a
part of the output (eg "TASK COMPLETE" string) ?
5) I see there are no CLI tests for object operations (eg cobbler distro
add). I thought that might be on purpose because
XML-RPC tests already cover the main logic of these operations, but then
the same would apply to direct commands and testing
them would not be needed. I assume these tests are missing because
nobody implemented them yet?
Regards,
Alan Evangelista
10 years
Older Python versions support
by Alan Evangelista
I do not know the criteria to define lower Python version supported in
Cobbler, but I'd guess RHEL life cycle is one of them.
Active RHEL versions are 5 and 6 and RHEL 5 uses Python 2.4. Is there a
reason to still support Python 2.3?
If not, is there anyone working toremove support to older Python
versions in Cobbler (eg require Cobbler 2.4+ instead of 2.3+)?
I see some simplifications which could be made to code (eg delete
cobbler/sub_process.py) if Python 2.3 support was not required.
Regards,
Alan Evangelista
10 years, 1 month
