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
10 years, 1 month
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
10 years, 1 month
Re: [cobbler-devel] [cobbler] Cobbler 2.4.4 released
by Santosh Kumar Gupta
Hi Sharuzzaman,
Read the available pydoc (*pydoc cobbler.remote*) or for more in-depth dig
into *remote.py*
Regards
On Tue, Apr 22, 2014 at 2:42 PM, Sharuzzaman Ahmat Raslan <
sharuzzaman(a)gmail.com> wrote:
> Hi Cobbler developers/users,
>
> May I know where I can get more information regarding Cobbler RPC?
>
> In Cobbler website, the URL
> http://www.cobblerd.org/manuals/developer/3_-_Xmlrpc.html shows that
> Cobbler is using XMLRPC, but in Red Hat Satellite 5.6 (cobbler 2.0.4), what
> I found out is that the result was returned in JSON, not XML. Is this
> common?
>
> Also, I'm looking for a full list of RPC capability of Cobbler, as the
> information in the URL only show some, but not all.
>
> MAN file did not have a full list RPC capability
>
> Docs folder in Github also did not have full list.
>
> Appreciate if I can have pointers on how to fully utilize the RPC of
> cobbler
>
> Thanks.
>
>
>
>
> On Tue, Apr 22, 2014 at 3:39 PM, Jörgen Maas <jorgen.maas(a)gmail.com>wrote:
>
>> Hey all,
>>
>> I just tagged and released Cobbler 2.4.4.This is once again a very minor
>> bugfix release.
>>
>> Please note that the Cobbler 2.4.x series will be the last series
>> supporting python 2.4 (eg. RHEL 5)
>>
>> Improved Features:
>>
>> - Add a distro_signature for Ubuntu 14.04
>> - Add an option to always write DHCP entries regardless of netboot
>> setting
>> - Improve support for running inside chroot() and/or containers
>> - Improve performance of the "cobbler sync" operation
>>
>> Bugfixes:
>>
>> - Fix infinite loop in get_file_device_path() in chroot environment
>> - Fixed an Exception in Koans get_insert_script() function
>>
>> The (source) release can be found here<https://github.com/cobbler/cobbler/releases/tag/v2.4.4>
>>
>> Fedora packages:
>>
>> - Fedora 18<http://download.opensuse.org/repositories/home:/libertas-ict:/cobbler24/F...>
>> - Fedora 19<http://download.opensuse.org/repositories/home:/libertas-ict:/cobbler24/F...>
>> - Fedora 20<http://download.opensuse.org/repositories/home:/libertas-ict:/cobbler24/F...>
>>
>>
>>
>> --
>> Grtz,
>> Jörgen Maas
>>
>> _______________________________________________
>> cobbler mailing list
>> cobbler(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/cobbler
>>
>>
>
>
> --
> Sharuzzaman Ahmat Raslan
>
> _______________________________________________
> cobbler mailing list
> cobbler(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/cobbler
>
>
10 years, 2 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, 2 months
Triggers parameters
by Santosh Kumar Gupta
Hello List,
I'm about to write my first trigger but I'm not getting any documentation
for parameter passed to the triggers.
I'm writing a post trigger for distro import just wanted to know the
parameters passed to the trigger.
Regards
10 years, 2 months
