Hi there
On 20.05.2016 19:59, Alexander von Gluck IV wrote:
> When I spoke to mmlr, it seemed he didn't have much interest in making a
> web interface. (speak up mmlr if i'm wrong)
It isn't much about interest but about time. Unfortunately I am so
insanely busy with work right now (and for the foreseeable future) that
I just couldn't make any commitment above a couple of hours per week.
I've offered to move/set up a buildmaster on a Haiku Inc. owned VM a
couple of times before, but we never got far enough to exchange actual
login credentials to make it possible. That offer still stands.
> Is there a python expert out there who would be interested in exposing a
> REST api in haikuporter running in master mode?
I do not exactly understand what you're hoping to gain from that. I've
designed the buildmaster mode so that it can be statically served
directly from the filesystem. Everything you see at
https://hpkg.mlotz.ch/x86_gcc2/buildmaster.html is aggregated from a
status file in JSON format which is interpreted and presented client
side by JavaScript. If you take a look at
https://hpkg.mlotz.ch/x86_gcc2/ you'll get the directory listing where
everything can be had as individual files. The buildruns directory holds
the outputs of all the buildruns (listed in buildruns.txt for
convenience) while the output directory is a symlink to the output of
the current buildrun. The status.json holds all of the status, the
master.log and the logs in the builders and builds directories are the
plain text logs linked based on the info within the status.json.
So if you need structured output to feed into a web application then
just fetch the status.json. I know it's just a boring HTTP GET and not a
full fancy RESTful API, but the data you get back is the exact same.
I built it this way because this is the simplest and least resource
consuming way I could think of. The buildmaster is running on a m2.tiny
instance on AWS and still has plenty of headroom resource wise to
actually do haikuporter stuff because it does the minimum it needs to on
everything else. The parsing and presentation of the status happens
client side. I don't really see why this should consume server
resources, but I'm a purist.
> etc. Making on-the-fly buildmaster changes (post) would be nice as well
> down the road.
Let me describe how the buildmaster mode is designed to work:
Buildmaster mode is run oriented. It is not a service that always runs.
The buildmaster/buildmaster.sh script is a frontend to haikuporter in
buildmaster mode that exposes the "update" (pull the haikuports
repository and do a buildrun with the recipes that are affected by the
updated files), the "everything" (build all recipes) and the "build"
(build a specific recipe) commands.
The server I have set up is meant to watch and build recipes from a
certain repository/branch (haikuports master right now). So there is a
script that just has a loop of buildmaster/buildmaster.sh update,
buildmaster/creterepo.sh and sleep 180. This exists three times, once
for x86_gcc2, x86 and x86_64 in separate directories on the server.
This setup might seem strange to someone used to always available web
applications, but since it is fully task oriented it can scale rather well.
An API to manipulate the buildmaster when its running (to reinstate a
lost builder, cancel a buildrun or add/remove recipes to a buildrun for
example) might make sense. However it was not built to do that. The
intention was for it to stay a tool that does its job and not to build
webserver capabilities into it. The idea was to later add a managing
frontend application that then runs haikuporter in buildmaster mode to
get builds done and exposes an API to request specific builds and abort
running buildruns. This frontend would then replace the crude script
with the loop mentioned above.
> Having a RESTful control interface exposed in the master service would
> let people make an interface in whatever language
> they see fit. (crazy node.ns, ruby, more python, etc) :-) Hell, my
> rails Haikeuken project could be modified to poll build status info
> pretty easily.
Again I fail to see what prevents you from just polling that status info
as it is right now. I've even previously explained this setup and
pointed to status.json, but apparently noone took a look.
> What I know based on trying to stand it up on my own:
> * haikuporter buildmaster runs on Linux
It does because that was the easiest way to get it run in a public
cloud. As it only depends on the package and package_repo tools which
are both available on Linux as part of the normal Haiku build, this was
easy enough.
It connects to builders using SSH via the paramiko Python module. That
one builds on non-gcc2 Haiku, but I have not actually tested it. If it
works, there shouldn't be anything hindering deployment on Haiku. As the
buildmaster host is mostly a coordinating web and storage server it
probably doesn't make much sense to actually run on Haiku though.
> * haikuporter buildmaster ssh' out to remote Haiku build machines via
> a pre-set keypair
Yes. As with the buildruns this is stateless and on demand, so a
connection is made when a build should be scheduled on a builder. The
connection is kept open once it is established, but it's not a permanent
and monitored connection.
The buildmaster ensures that the repository on the builder is at the
same commit as the one the buildmaster is using, pushes any missing
dependency packages to the builder, runs haikuporter for the desired
recipe and finally downloads the resulting packages. It does all of that
via SSH/SFTP.
Since SSH is easily forwardable, a setup with a reverse SSH tunnel can
be used for convenience. My builder at home does that so I don't have to
bother with dynamic IPs and router configuration.
> If we want to get fancy, we could run the buildmaster on haiku hardware,
> and have a few buildslaves in AWS.
The problem with that is that the default networking hardware (Xen /
virtio_net) used by most public clouds is not supported under Haiku. In
OpenStack clouds that use KVM you can usually configure the networking
hardware to e1000, which works fine. I've set up Haiku VMs in such
clouds. Generally this isn't very cost effective as such on demand
instances tend to be rather expensive. Getting another large server at
Hetzner or putting more VMs on the one we already have is probably more
sensible.
I notice and appreciate the offers for computing power we get from the
community. But, without wanting to appear too paranoid, there is a
certain inherent trust issue at play here. These builders will produce
the packages that will be delivered by default with new Haiku
installations and the host building them therefore needs to be fully
trusted. This isn't so much of a problem with 3rd party repositories
where the user actively decides to trust that 3rd party. For the
packages provided by default I personally would prefer to have them
built on hardware owned by Haiku Inc. or people that are directly
involved with the relevant systems anyway.
> Nothing super complete, but i did some detangling of the buildmaster
deployment steps today:
https://github.com/haikuports/haikuporter/blob/master/README.md
