mirror of
git://git.proxmox.com/git/pve-common.git
synced 2024-12-22 21:33:47 +03:00
242 lines
7.0 KiB
Plaintext
242 lines
7.0 KiB
Plaintext
= Setup PVE Development Environment =
|
|
|
|
1. Install Debian 'stretch'
|
|
2. Configure pvetest repository in apt sources.list
|
|
|
|
deb http://download.proxmox.com/debian stretch pvetest
|
|
|
|
3. Add our repository key with apt-key:
|
|
|
|
wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -
|
|
|
|
4. make sure you have a read IP address for your hostname in /etc/hosts
|
|
(using 127.0.1.1 will not work)
|
|
|
|
5. run: apt-get update
|
|
6. run: apt-get dist-upgrade
|
|
7. run: apt-get install proxmox-ve
|
|
|
|
You should now have a working Proxmox VE installation.
|
|
|
|
= Install build prerequisites for development environment =
|
|
|
|
apt-get install build-essential git git-email debhelper \
|
|
autotools-dev autogen dh-autoreconf dkms doxygen check pkg-config \
|
|
groff quilt dpatch automake autoconf libtool lintian libdevel-cycle-perl \
|
|
libjson-perl libcommon-sense-perl liblinux-inotify2-perl libio-stringy-perl \
|
|
libstring-shellquote-perl dh-systemd rpm2cpio libsqlite3-dev sqlite3 \
|
|
libglib2.0-dev librrd-dev librrds-perl rrdcached libdigest-hmac-perl \
|
|
libxml-parser-perl gdb libcrypt-openssl-random-perl \
|
|
libcrypt-openssl-rsa-perl libnet-ldap-perl libauthen-pam-perl \
|
|
libjson-xs-perl libterm-readline-gnu-perl oathtool libmime-base32-perl \
|
|
liboath0 libpci-dev texi2html libsdl1.2-dev libgnutls28-dev \
|
|
libspice-protocol-dev xfslibs-dev libnuma-dev libaio-dev \
|
|
pve-libspice-server-dev libusbredirparser-dev glusterfs-common \
|
|
libusb-1.0-0-dev librbd-dev libpopt-dev iproute bridge-utils numactl \
|
|
glusterfs-common ceph-common python-ceph libgoogle-perftools4 \
|
|
libfile-chdir-perl lvm2 glusterfs-client liblockfile-simple-perl \
|
|
libsystemd-dev libreadline-gplv2-dev libio-multiplex-perl \
|
|
libnetfilter-log-dev libipset3 ipset socat libsasl2-dev libogg-dev \
|
|
python-pyparsing libfilesys-df-perl libcrypt-ssleay-perl \
|
|
libfile-readbackwards-perl libanyevent-perl libanyevent-http-perl \
|
|
unzip liblocale-po-perl libfile-sync-perl cstream \
|
|
lzop dtach apt-transport-https hdparm gdisk parted ttf-dejavu-core \
|
|
liblzma-dev dosfstools mtools libxen-dev libfuse-dev corosync-dev \
|
|
libcpg-dev libquorum-dev libcmap-dev libuuid-perl \
|
|
libqb-dev libapparmor-dev docbook2x libcap-dev dh-apparmor \
|
|
graphviz libseccomp-dev libglib-perl libgtk3-perl libnss3-dev libdlm-dev \
|
|
libudev-dev asciidoc-dblatex source-highlight libiscsi-dev libiscsi7
|
|
|
|
= Compile PVE packages from Source =
|
|
|
|
Download and install the following git modules in order from top to bottom:
|
|
|
|
# git clone git://git.proxmox.com/git/<PACKAGE.git>
|
|
|
|
You currently need the following packages:
|
|
|
|
pve-common.git
|
|
libpve-http-server-perl.git
|
|
libpve-apiclient-perl.git
|
|
pve-docs.git
|
|
pve-cluster.git
|
|
pve-access-control.git
|
|
pve-storage.git
|
|
pve-guest-common.git
|
|
pve-firewall.git
|
|
pve-qemu-kvm.git
|
|
qemu-server.git
|
|
vncterm.git
|
|
spiceterm.git
|
|
#vzquota.git
|
|
#vzctl.git
|
|
#fence-agents-pve.git
|
|
#resource-agents-pve.git
|
|
extjs.git
|
|
pve-manager.git
|
|
#pve-kernel-3.10.0.git
|
|
#libiscsi.git
|
|
#gfs2-utils.git
|
|
ksm-control-daemon.git
|
|
pve-container.git
|
|
pve-kernel.git
|
|
|
|
Most packages can be installed with 'make dinstall' command.
|
|
|
|
4. Reboot the system.
|
|
5. Learn to use the quilt patch scripts.
|
|
6. Happy coding.
|
|
|
|
There is an experimental package containing the API documentation
|
|
as ExtJS application:
|
|
|
|
pve2-api-doc.git
|
|
|
|
You can view the source code at:
|
|
|
|
https://git.proxmox.com
|
|
|
|
|
|
= REST vs. SOAP =
|
|
|
|
We decided to change our SOAP API (1.X) and use a REST like API. The
|
|
concept is described in [1] (Resource Oriented Architecture
|
|
(ROA)). The main advantage is that we are able to remove a lot of code
|
|
(the whole SOAP stack) to reduce software complexity.
|
|
|
|
We also moved away from server side content generation. Instead we use
|
|
the ExtJS Rich Internet Application Framework
|
|
(http://www.sencha.com).
|
|
|
|
That framework, like any other AJAX toolkit, can talk directly to the
|
|
REST API using JSON. So we were able to remove the server side
|
|
template toolkit completely.
|
|
|
|
= JSON and JSON Schema =
|
|
|
|
We use JSON as data format, because it is simple and parse-able by any
|
|
web browser.
|
|
|
|
Additionally, we use JSON Schema [2] to formally describe our API. So
|
|
we can automatically generate the whole API Documentation, and we can
|
|
verify all parameters and return values.
|
|
|
|
A great side effect was that we are able to use JSON Schema to
|
|
produce command line argument parsers automatically. In fact, the REST
|
|
API and the command line tools use the same code.
|
|
|
|
Object linkage is done using the JSON Hyper Schema (links property).
|
|
|
|
A small utility called 'pvesh' exposes the whole REST API on the command
|
|
line.
|
|
|
|
So here is a summary of the advantage:
|
|
|
|
- easy, human readable data format (native web browser format)
|
|
- automatic parameter verification (we can also verify return values)
|
|
- automatic generation of API documentation
|
|
- easy way to create command line tools (using same API).
|
|
|
|
= API Implementation (PVE::RESTHandler) =
|
|
|
|
All classes exposing methods on the API use PVE::RESTHandler as base class.
|
|
|
|
use base qw(PVE::RESTHandler);
|
|
|
|
To expose methods, one needs to call register_method():
|
|
|
|
__PACKAGE__->register_method ($schema);
|
|
|
|
Where $schema is a PVE method schema as described in
|
|
PVE::JSONSchema. It includes a description of parameters and return
|
|
values, and a reference to the actual code
|
|
|
|
__PACKAGE__->register_method ({
|
|
name => 'echo',
|
|
path => 'echo',
|
|
method => 'GET',
|
|
description => "simple return value of parameter 'text'",
|
|
parameters => {
|
|
additionalProperties => 0,
|
|
properties => {
|
|
text => {
|
|
type => 'string',
|
|
}
|
|
},
|
|
},
|
|
returns => {
|
|
type => 'string',
|
|
},
|
|
code => sub {
|
|
my ($param) = @_;
|
|
|
|
return $param->{text};
|
|
}
|
|
});
|
|
|
|
The 'name' property is only used if you want to call the method
|
|
directly from Perl. You can do that using:
|
|
|
|
print __PACKAGE__->echo({ text => "a test" });
|
|
|
|
We use Perl's AUTOLOAD feature to implement this. Note: You need to
|
|
pass parameters a HASH reference.
|
|
|
|
There is a special helper method called cli_handler(). This is used by
|
|
the CLIHandler Class for command line tools, where you want to pass
|
|
arguments as array of strings. This uses Getopt::Long to parse parameters.
|
|
|
|
There is a second way to map names to methods - using the 'path'
|
|
property. And you can register subclasses. That way you can set up a
|
|
filesystem like hierarchy to access methods.
|
|
|
|
Here is an example:
|
|
----------------------------
|
|
package C1;
|
|
|
|
__PACKAGE__->register_method ({
|
|
subclass => "C2",
|
|
path => 'sub2',
|
|
});
|
|
|
|
|
|
__PACKAGE__->register_method ({
|
|
name => 'list1',
|
|
path => 'index',
|
|
method => 'GET',
|
|
...
|
|
});
|
|
|
|
package C2;
|
|
|
|
__PACKAGE__->register_method ({
|
|
name => 'list2',
|
|
path => 'index',
|
|
method => 'GET',
|
|
...
|
|
});
|
|
-------------------------------
|
|
|
|
The utily method find_handler (in PVE::RESTHandler) can be use to do
|
|
'path' related method lookups.
|
|
|
|
C1->find_handler('GET', "/index") => C1::list1
|
|
C1->find_handler('GET', "/sub2/index") => C2::list2
|
|
|
|
The HTTP server use the URL (a path) to find the corresponding method.
|
|
|
|
|
|
= References =
|
|
|
|
[1] RESTful Web Services
|
|
Web services for the real world
|
|
|
|
By
|
|
Leonard Richardson, Sam Ruby
|
|
Publisher:
|
|
O'Reilly Media
|
|
Released:
|
|
May 2007
|
|
|
|
[2] JSON Schema links: http://json-schema.org/
|