So, more LXD, here we go! Today we are going to see how to access our LXD containers from outside of the system running LXD itself.
If you are just trying out stuff (like I am), you probably installed some Ubuntu version on a VM in order to run LXD. This means that by default you have no access to your containers from your system, just from the system running LXD.
A simple solution is to add a route to the isolated network that the container get, going through the host running LXD:
ip route add addr:10.0.3.0/24 via 192.168.99.28
Here we are telling our system that the 10.0.3.0/24 network is routable through 192.168.99.28, our LXD machine.
You probably don’t want to use something like this in production, but we are exporing here! 🙂
I have been playing around with LXD the past few nights, and so far I really like it. It’s like VMs, but as a container, in contrast with Docker, which is designed around running a single application as a container.
In order to try LXD out I installed a Ubuntu 15.10 VM and added the LXD stable PPA. Then it was time to launch some containers!
lxc remote add images images.linuxcontainers.org
lxc image copy images:debian/jessie/amd64 local: --alias jessie-amd64
lxc launch jessie-amd64 jessie-test
Shortly after I hit a problem: I could not stop the container I just created! It would just hang there, so I had to stop it forcefully:
lxc stop --force jessie-test
That doesn’t look good at all. Digging around I found the issue on GitHub, which basically concludes that it’s a systemd issue, because it doesn’t seem to handle SIGPWR correctly. Oh boy. The systemd issue is still open on Launchpad, so what do we do then? Well, we get rid of systemd. Let’s prepare a base Debian Jessie image with good old SysV init, shall we?
lxc exec jessie-test /bin/bash
apt-get update && apt-get install sysvinit-core
lxc stop jessie-test --force
lxc start jessie-test
lxc exec jessie-test /bin/bash
apt-get remove --purge --auto-remove systemd
rm -rf /var/lib/apt/lists/*
rm -rf /var/cache/apt/archives/*
lxc stop jessie-test
lxc publish jessie-test --alias jessie-amd64-base-sysvinit
Now all containers we create with our new and shiny image will stop gracefully.
I have recently released new versions of 3 of my Python modules (pyuv, pycares and python-fibers), which happen to be Python C extensions.
While preparing these releases, I decided to give AppVeyor a try, since it can be used for both integration testing on Windows and Python Wheels generation. I managed to do so following these instructions and checking this project example, and I was (almost) all set.
The missing part was to download all those built artifacts (the Python wheels) stored in AppVeyor and upload them to PyPI when I decided to make a release. Uploading the wheels can be easily done using twine, and for downloading the last built artifacts for a given project I created the following simple Python script using requests:
Using it is simple:
appveyor-download --api-token 1234 --user saghul --project pyuv
I hope you find it useful!
Quick heads up, I just released pyuv 1.2.0. pyuv is a Python wrapper for libuv. This time around, pyuv implements all the funcionality covering up to libuv 1.7.3.
This release was focused in 2 things: adjusting to new APIs / changes in libuv, and improving the testing, specifically on Windows.
As of this writing, pyuv is automatically tested on Linux systems thanks to Travis CI and on Windows thanks to AppVeyor. Thanks to AppVeyor, I’m now able to provide Python Wheels for pyuv, which is great because, frankly, compiling it on Windows is kind of a pain.
See the ChangeLog for a detailed outline of the changes, check the documentation, and fetch the code on GitHub. Packages have also been uploaded to PyPI.
Yeah, it must be 1.0.0 release week!
I’m happy to announce python-fibers 1.0.0! Fibers are cooperative microthreads for Python, a project I started about a couple of years ago. Head here for the initial project annoucement and rationale. (yes, I can hear you thinking “why didn’t he use greenlet?!”)
There are no API changes in this release, and since it has been stable so far I thought it it’s fair to call it a 1.0.
This release steps up the CI game by adding AppVeyor integration, and thanks to it we have binary Python wheels for Python 2.7, 3.3 and 3.4 on PyPI!
As usual, the code is available on GitHub and documentation on RTD.
Long time no blog!
Today I’m happy to announce pycares 1.0.0 was just released. pycares is a Python library which wrapps the c-ares C library, providing asynchronous DNS resolution capability to different applications.
The full changelog can be checked here, but these are the main highlights:
- Return nametuple-like objects for all query types
- Return TTL information
- Dropped support for old Python versions
- AppVeyor CI integration
- Binary wheels available for 32 and 64 bit Windows (thanks AppVeyor!)
As usual, the code is available on GitHub and the documentation is here.
It’s with great pleasure that today, the day when OpenBSD 5.7 was released, I can announce OpenHRC: Open Household Router Contraption.
OpenHRC is a project Iñigo and yours truly did in our spare time, in order to replace the (crappy) router our Internet provider gave us with something more robust and OpenBSD based.
We chose the PC Engines APU as our hardware platform, but any device with at least 2 network interfaces will do. OpenHRC uses Ansible to configure the basic OpenBSD installation and enable several services, configured with sane defaults:
- Local NTP server
- DHCP server
- Local caching DNS resolver
This is just the beginning, we will be adding more features shortly, but we couldn’t pass on making our first release the same day OpenBSD 5.7 (which we have been testing for some time) is released.
Check out the installation video below, and head over to GitHub for the source code. Happy routing!
Yes, it’s that time of the year again. The week which leads to one of my favorite conferences: FOSDEM. I’ve been attending for 4 or 5 years now and I love it. There is so much going on it even get overwhelming at times! It’s great to just hop into a random room and listen to a great talk, my brain becomes a sponge throughout the weekend 🙂
This year I’ll be giving a talk at the lightning talks track and another talk at the Python devroom. As usual, I’m super excited.
See you there?
If you are a Python user which happens to use Windows every now and then you probably also suffer when installing (or at least trying to) Python packages which need to be compiled. Python wheels really help here, as they ease the installation of binary packages, and even make the installation of non-binary packages faster.
Long time pyuv contributor Marc Schlaich has recently began to provide these wheels for both 32 and 64 Windows, for all supported Python versions: 2.7, 3.3 and 3.4. Wheels for pyuv 1.0.2 have already been uploaded to PyPI, you can check how to install Python wheels here.
Thanks a lot for your contributions Marc!
In case you missed the news, libuv 1.0.0 was released not long ago, so now it’s time for pyuv to hit 1.0.0.
Hitting 1.0.0 means the API will remain backwards compatible throughout the 1.x branch. But this came at a cost: pyuv 1.0.0 introduced several backwards incompatible API changes, some coming from changes in libuv itself, and some others to (hopefully) improve pyuv itself.
Here is the full changelog.
As usual, you can download pyuv from PyPI, and check the documentation here.
“So, what now?” I hear you say. Since pyuv is currently feature-complete with regards to libuv, adding CFFI bindings to pyuv will probably be the next thing I’ll tackle. You can follow the discussion here. A user already started, and I look forward to joining forces and integrating the work 🙂