This is a foolish RFE that I have been thinking about for quite sometimes.
It is a consequence of my recent work on : http://
<goog_380723797>bitbucket<goog_380723797>
.org/ <goog_380723797>yml <goog_380723797>/
<goog_380723797>cherokee<goog_380723797>
-admin-api
cherokee-admin is a great asset for cherokee because it eases the
configuration of the webserver by providing the best user experience to edit
a server config file.
I think that decoupling cherokee-admin and package it as a standalone python
application could open up some new horizon.
cherokee-admin is bound to the cherokee installation that it has been
install with. At installation time the value for : PREFIX, LIBDIR, DATADIR,
DOCDIR, LOCALEDIR, WWWROOT, SYSCONFDIR, LOCALSTATE, VERSION, ... And some
others that I have probably missed. All this info could be probably sent by
a specific handle 'verbose_instalation_parameters' that could return a nice
format neutral / easy to parse response (json, xml, yaml, ...). It would
allows us to use one cherokee-admin for many servers, the only requirement
would be to be able to access the cherokee configuration file (in read,
write). This could be a baby step in the cherokee tribe that I see poping up
from time to time.
The next item that I find painful in the actual architecture is the
validation of the cherokee configuration. As of now the only tool I am aware
of is "cheroke -C <the config file> -t". This is already very useful but
using it programmatically is a bit of pain. For some reason that I have not
yet understood the exit status when it is ok is not 0 but 2. In addition
when I run this the output get actually printed to stdout instead of only
being captured. (SIDETRACK= To better understand this you can run the test
suite in cherokee-admin-api). The previous is not a huge problem I more
worried about the granularity of this command. Ideally in the perfect world
I would like to be able to run this at different level of the configuration
file. For example it would be nice to be able to validate a rule or a new
vserver ...
"""
def is_valid_config(config_file): args = shlex.split("cherokee -C
%s -t" %config_file) validation_result = subprocess.call(args)
proc = subprocess.Popen(args,
stdin=subprocess.PIPE,
stderr=subprocess.PIPE,
stdout=subprocess.PIPE) EXPECTED_STDERR = 'Test on %s: OK\n'
%config_file if proc.stderr.read() == EXPECTED_STDERR:
return True else: return False
"""
The last point is about the abstraction to manipulate the configuration
itself, it clearly leaks the underlying storage format. The config.py makes
a relative good job at turning the cherokee 's config file into a python
dict. Unfortunately the abstraction stop there so you can't really do
anything without clear understanding of the storage format and if you add
this with the lack of partial validation, it makes the development of script
a bit more painful than it should.
What is the kind new domain that I think could be tackle with this new
infrastructure in place :
* automatic migration script to migrate from another web server (at least
partial).
* automatic generation of the cherokee.conf for a deployment in the cloud.
* enable the creation of new python packages that leverage this low level
infrastructure.
* simplify and unittest the actual cherokee-admin
I would be glad to hear your thinking on this area and about your vision for
the evolution of cherokee-admin. If you think that I should read, watch some
of the material that have been produced please do not hesitate to send me
the links.
Regards,
--yml
_______________________________________________
Cherokee mailing list
[email protected]
http://lists.octality.com/listinfo/cherokee
