Conference

High level themes from CloudCon 2025

  • Post author:
  • Post category:Conference

I've just been in Sydney for a couple of days for CloudCon 2025. I think depending on how you count this is my third one of these events -- the event has changed names at least twice, so its actually a little hard to work out the lineage of the event. This year's conference was noticeably smaller than last years which is confusing to me for an event which is so competitively priced and branded so heavily with the hot topics dejour. That said the event was well run, in a good venue, and well worth the time. That is, this event really deserves more support than its getting. There were some clear themes from the event for me: ClickHouse is cool. Or at least I think so. ClickHouse observability certainly has potential, but I think the underlying SQL database is actually the most interesting bit. ClickHouse is also investing heavily in the Australian market right now, so I suspect they're seeing strong traction here. No one talks about "devops" any more, because its become a meaningless term where everything is devops if you squint at it right. Instead people are using the term "platform engineering", which doesn't appear to have…

Continue ReadingHigh level themes from CloudCon 2025

Rejected talk proposal: Shaken Fist, thought experiments in simpler IaaS clouds

This proposal was submitted for FOSDEM 2021. Given that acceptances were meant to be sent out on 25 December and its basically a week later I think we can assume that its been rejected. I've recently been writing up my rejected proposals, partially because I've put in the effort to write them and they might be useful elsewhere, but also because I think its important to demonstrate that its not unusual for experienced speakers to be rejected from these events. OpenStack today is a complicated beast -- not only does it try to perform well for large clusters, but it also embraces a diverse set of possible implementations from hypervisors, storage, networking, and more. This was a deliberate tactical choice made by the OpenStack community years ago, forming a so called "Big Tent" for vendors to collaborate in to build Open Source cloud options. It made a lot of sense at the time to be honest. However, OpenStack today finds itself constrained by the large number of permutations it must support, ten years of software and backwards compatability legacy, and a decreasing investment from those same vendors that OpenStack courted so actively. Shaken Fist makes a series of simplifying assumptions…

Continue ReadingRejected talk proposal: Shaken Fist, thought experiments in simpler IaaS clouds

Support for Raspberry Pi and Orange Pi GPIOs in Home Assistant

So, I've been off in the GPIO library salt mines for a while, but am now ready to circle back and document how to get GPIO inputs and outputs working in Home Assistant. This now works on both Raspberry Pi and OrangePi, assuming that my patch gets merged. First off, let's talk about GPIO outputs. This is something which has been working for a while on both platforms (a while being a week or so, assuming you've patched Home Assistant with my pull request, but you're all doing that right?). To configure an output in Home Assistant, you would add the following to configuration.yaml: rpi_gpio: board_family: orange_pi switch: - platform: rpi_gpio ports: PA7: LED Where board_family can be either "raspberry_pi" or "orange_pi". Note that for Raspberry Pis, the pin numbers are always numbers whereas for OrangePi we are using "SUNXI" numbering, which is of the form "PA7". The circuit for this LED is really simple: Now we have a switch we can control in Home Assistant: GPIO inputs are similar. The configuration looks like this: rpi_gpio: board_family: orange_pi binary_sensor: - platform: rpi_gpio invert_logic: true ports: PA7: PUSHYBUTTON With a circuit like this: invert_logic set to true is required because our…

Continue ReadingSupport for Raspberry Pi and Orange Pi GPIOs in Home Assistant

Updated examples for OrangePi GPIOs

As part of working through adding OrangePi support to Home Assistant, Alastair and I decided to change to a different GPIO library for OrangePi to avoid the requirement for Home Assistant to have access to /dev/mem. I just realised that I hadn't posted updated examples of how to do GPIO output with the new library. So here's a quick post about that. Assuming that we have an LED on GPIO PA7, which is pin 29, then the code to blink the LED would look like this with the new library: import OPi.GPIO as GPIO import time # Note that we use SUNXI mappings here because its way less confusing than # board mappsings. For example, these are all the same pin: # sunxi: PA7 (the label on the board) # board: 29 # gpio: 7 GPIO.setmode(GPIO.SUNXI) GPIO.setwarnings(False) GPIO.setup('PA7', GPIO.OUT) while True: GPIO.output('PA7', GPIO.HIGH) time.sleep(1) GPIO.output('PA7', GPIO.LOW) time.sleep(1) The most important thing there is the note about SUNXI pin mappings. I find the whole mapping scheme hugely confusing, unless you use SUNXI and then its all fine. So learn from my fail people! What about input? Well, that's not too bad either. Let's assume that you have a button in a…

Continue ReadingUpdated examples for OrangePi GPIOs

GPIO inputs on Raspberry Pi

Now that I have GPIO outputs working nicely for Home Assistant using either a Raspberry Pi or an Orange Pi, I want to get GPIO inputs working as well. Naively, that's pretty easy to do in python on the Raspberry Pi: import RPi.GPIO as GPIO import time GPIO.setmode(GPIO.BCM) GPIO.setwarnings(False) GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_DOWN) while True: print('Reading...') if GPIO.input(17) == GPIO.HIGH: print('Pressed') else: print('Released') time.sleep(1) That code is of course horrid. Its horrid because its polling the state of the button, and its quite likely that I can sneak a button press in during one of those sleeps and it will never be noticed. Instead we can use edge detection callbacks to be informed of button presses as they happen: import RPi.GPIO as GPIO import time GPIO.setmode(GPIO.BCM) GPIO.setwarnings(False) GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_DOWN) def event_callback(channel): print('Event detected: %s' % GPIO.input(17)) GPIO.add_event_detect(17, GPIO.BOTH, callback=event_callback, bouncetime=50) while True: time.sleep(1) This second program provides helpful output like this: pi@raspberrypi:~ $ python gpio_button_edge_detect.py Event detected: 1 Event detected: 0 Which is me pressing the button once (it go high when pressed, and then low again when released). This is of course with a button wired to GPIO17 with a current limiting resistor between the button and the 3.3v…

Continue ReadingGPIO inputs on Raspberry Pi

Pull Requests for the LCA2019 Home Automation tutorial

A quick list of things I did for the LCA2019 Home Automation tutorial. Of course Alistair did a lot more, but I still want to track these. Add OrangePi GPIO support to Home Assistant (declined) Document OrangePi GPIO support in Home Assistant (declined) Add OrangePi Prime GPIO pinouts to OPi.GPIO (merged, and released) Expose pullup resistor constants in OPi.PGIO (merged, and released) A simple burn in script for the workshop boards (merged) Automated generation of dhcpd.conf for the workshop network (merged) Clarifications for the workshop prerequisites (merged) Not all pins on Orange Pi support edge detection Clarify where the GPIO header is on the LCA2019 shield

Continue ReadingPull Requests for the LCA2019 Home Automation tutorial

Further adventures in Home Assistant OrangePi GPIO

Its funny how a single sentence can change your course. In the last post about this work, I said: We also need to run hass as root,  because OrangePi GPIO support requires access to /dev/mem for reasons I haven’t dug into just yet. That's turned out to be (reasonably) a pretty big sticking point upstream. Access to /dev/mem gives you a whole bunch of access to the machine that Home Assistant probably shouldn't have. Alastair went off spelunking because he's more patient than me and found yet another OrangePi GPIO library. I think we're up to three or four of these at the moment, but this is the first one we've found which supports the sysfs interface to GPIO pins. That's exciting because it removes our run-as-root requirement. Its unexciting in that the sysfs interface has been deprecated by the kernel, but will remain supported for a while. I think people would be within their rights to conclude that the state of GPIO libraries for OrangePi is a bit of a dumpster fire right now. Anyways, the point of this post is mostly to write down how to use the sysfs interface to GPIO pins so that I can remember it later,…

Continue ReadingFurther adventures in Home Assistant OrangePi GPIO

Adventures in Home Assistant Raspberry Pi GPIO

Alastair D'Silva is running what looks to be a very well prepared home automation tutorial at LCA2019 based on Home Assistant. I offered to have a hack on the support for GPIO pins on OrangePi boards in Home Assistant because it sounded interesting for a vacation week. The only catch being that I'd never done anything with GPIO pins at all on either Raspberry Pi or Orange Pi. The first step seemed to be to get GPIO working at all on a Raspberry Pi (which is currently supported out of the box with Home Assistant). This online tutorial has a simple example of a circuit and the associated python code to blink a LED on a Raspberry Pi, so off I went to build that circuit. The circuit has a LED with a 330 ohm pull up resistor on GPIO pin 18 on the board. The sample python code on the page above just blinks that LED, which I used to make sure that the circuit as working as intended. To configure the GPIO pin as a switch in Home Assistant, I added the following to configuration.yaml (noting that the empty rpi_gpio entry isn't strictly required, but will be later): rpi_gpio: switch: -…

Continue ReadingAdventures in Home Assistant Raspberry Pi GPIO

Learning from the mistakes that even big projects make

The following is a blog post version of a talk presented at pyconau 2018. Slides for the presentation can be found here (as Microsoft powerpoint, or as PDF), and a video of the talk (thanks NextDayVideo!) is below:

 

OpenStack is an orchestration system for setting up virtual machines and associated other virtual resources such as networks and storage on clusters of computers. At a high level, OpenStack is just configuring existing facilities of the host operating system — there isn’t really a lot of difference between OpenStack and a room full of system admins frantically resolving tickets requesting virtual machines be setup. The only real difference is scale and predictability.

To do its job, OpenStack needs to be able to manipulate parts of the operating system which are normally reserved for administrative users. This talk is the story of how OpenStack has done that thing over time, what we learnt along the way, and what I’d do differently if I had my time again. Lots of systems need to do these things, so even if you never use OpenStack hopefully there are things to be learnt here.

(more…)

Continue ReadingLearning from the mistakes that even big projects make

The last week for linux.conf.au 2019 proposals!

Dear humans of the Internet -- there is ONE WEEK LEFT to propose talks for linux.conf.au 2019. LCA is one of the world's best open source conferences, and we'd love to hear you speak!   Unsure what to propose? Not sure if your talk is what the conference would normally take? Just want a chat? You're welcome to reach out to papers-chair@linux.org.au to talk things through.   https://linux.conf.au/call-for-papers/

Continue ReadingThe last week for linux.conf.au 2019 proposals!

End of content

No more pages to load

Older Posts