Made by Mikal – Page 33

My finished Thien Baffle.

Building a Thien Baffle

Post author:mikal
Post published:December 23, 2014
Post category:Hacks

For a while now I’ve been meaning to play with making a Thien Baffle for my garage workshop. The motivation is that whilst I have a quite nice 3HP dust extractor (for those in the market for such a thing — don’t spend $1,400 with some retailers — I am super happy with my $500 unit from Leda Machinery), I want to keep the number of times I change the bags to a bare minimum. I see the dust extractor as a way of controlling potentially dangerous very fine dust, whereas some of the machines in my workshop create a lot of very large shavings — the thicknesser seems like the most obvious culprit here. It would be cool to divert these larger shavings into a bin where I can just use them as garden mulch, and then save the dust extractor bags for the fine and more dangerous dust.

(more…)

Ghost

Post author:mikal
Post published:December 15, 2014
Post category:Book

Trigger warning, I suppose. This like a Tom Clancy book, but with weirder sex, much of it non-consensual. Also, not as well thought through or as well researched or as believable. I couldn't bring myself to finish it.

How are we going with Nova Kilo specs after our review day?

Post author:mikal
Post published:December 15, 2014
Post category:OpenStack

Time for another summary I think, because announcing the review day seems to have caused a rush of new specs to be filed (which wasn't really my intention, but hey). We did approve a fair few specs on the review day, so I think overall it was a success. Here's an updated summary of the state of play: API Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Consolidate all console access APIs into one: review 141065. Expose the lock status of an instance as a queryable item: review 127139 (abandoned); review 85928 (approved). Extend api to allow specifying vnic_type: review 138808. Implement instance tagging: review 127281 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Improve the return codes for the instance lock APIs: review 135506. Microversion support: review 127127 (approved). Move policy validation to just the API layer: review 127160. Nova Server Count API Extension: review 134279 (fast tracked). Provide a policy statement on the goals of our API policies:…

Soft deleting instances and the reclaim_instance_interval in Nova

Post author:mikal
Post published:December 15, 2014
Post category:OpenStack

I got asked the other day how the reclaim_instance_interval in Nova works, so I thought I'd write it up here in case its useful to other people. First off, there is a periodic task run the nova-compute process (or the computer manager as a developer would know it), which runs every reclaim_instance_interval seconds. It looks for instances in the SOFT_DELETED state which don't have any tasks running at the moment for the hypervisor node that nova-compute is running on. For each instance it finds, it checks if the instance has been soft deleted for at least reclaim_instance_interval seconds. This has the side effect from my reading of the code that an instance needs to be deleted for at least reclaim_instance_Interval seconds before it will be removed from disk, but that the instance might be up to approximately twice that age (if it was deleted just as the periodic task ran, it would skip the next run and therefore not be deleted for two intervals). Once these conditions are met, the instance is deleted from disk.

Specs for Kilo, an update

Post author:mikal
Post published:December 3, 2014
Post category:OpenStack

We're now a few weeks away from the kilo-1 milestone, so I thought it was time to update my summary of the Nova specifications that have been proposed so far. So here we go... API Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Expose the lock status of an instance as a queryable item: review 127139 (abandoned); review 85928 (approved). Implement instance tagging: review 127281 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Improve the return codes for the instance lock APIs: review 135506. Microversion support: review 127127 (approved). Move policy validation to just the API layer: review 127160. Nova Server Count API Extension: review 134279 (fast tracked). Provide a policy statement on the goals of our API policies: review 128560. Sorting enhancements: review 131868 (fast tracked, approved). Support JSON-Home for API extension discovery: review 130715. Support X509 keypairs: review 105034 (approved). API (EC2) Expand support for volume filtering in the EC2 API: review 104450. Implement tags for volumes and…

The Human Division

Post author:mikal
Post published:November 26, 2014
Post category:Book

I originally read this as a series of short stories released on the kindle, but the paperback collation of those has been out for a while and deserved a read. These stories are classic Scalzi, and read well. If you like the Old Man's War universe you will like this book. The chapters of the book are free standing because of how they were originally written, and that makes the book a bit disjointed. The cliff hanger at the end is also pretty annoying given the next book hasn't been released. So, an interesting experiment that perhaps isn't perfect, but is well worth the read.

Fast Food Nation

Post author:mikal
Post published:November 17, 2014
Post category:Book

I don't read a lot of non-fiction, but I decided to finally read this book having had it sit on the shelf for a few years. I'm glad I read it, but as someone who regularly eats in the US I am not sure if I should be glad or freaked out. The book is an interesting study in how industrialization without proper quality controls can have some pretty terrible side effects. I'm glad to live in a jurisdiction where we actively test for food quality and safety. The book is a good read, and I'd recommend it to people without weak stomaches.

Specs for Kilo

Post author:mikal
Post published:October 25, 2014
Post category:OpenStack

Here's an updated list of the specs currently proposed for Kilo. I wanted to produce this before I start travelling for the summit in the next couple of days because I think many of these will be required reading for the Nova track at the summit. API Add instance administrative lock status to the instance detail results: review 127139 (abandoned). Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Expose the lock status of an instance as a queryable item: review 85928 (approved). Implement instance tagging: review 127281 (fast tracked, approved). Implement tags for volumes and snapshots with the EC2 API: review 126553 (fast tracked, approved). Implement the v2.1 API: review 126452 (fast tracked, approved). Microversion support: review 127127. Move policy validation to just the API layer: review 127160. Provide a policy statement on the goals of our API policies: review 128560. Support X509 keypairs: review 105034. Administrative Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705…

One week of Nova Kilo specifications

Post author:mikal
Post published:October 14, 2014
Post category:OpenStack

Its been one week of specifications for Nova in Kilo. What are we seeing proposed so far? Here's a summary... API Add instance administrative lock status to the instance detail results: review 127139. Add more detailed network information to the metadata server: review 85673. Add separated policy rule for each v2.1 api: review 127863. Add user limits to the limits API (as well as project limits): review 127094. Allow all printable characters in resource names: review 126696. Implement instance tagging: review 127281. Implement tags for volumes and snapshots with the EC2 API: review 126553 (spec approved). Implement the v2.1 API: review 126452 (spec approved). Microversion support: review 127127. Move policy validation to just the API layer: review 127160. Support X509 keypairs: review 105034. Administrative Enable the nova metadata cache to be a shared resource to improve the hit rate: review 126705. Containers Service Initial specification: review 114044. Hypervisor: FreeBSD Implement support for FreeBSD networking in nova-network: review 127827. Hypervisor: Hyper-V Allow volumes to be stored on SMB shares instead of just iSCSI: review 102190. Hypervisor: VMWare Add ephemeral disk support to the VMware driver: review 126527 (spec approved). Add support for the HTML5 console: review 127283. Allow Nova to access…

Compute Kilo specs are open

Post author:mikal
Post published:October 13, 2014
Post category:OpenStack

From my email last week on the topic: I am pleased to announce that the specs process for nova in kilo is now open. There are some tweaks to the previous process, so please read this entire email before uploading your spec! Blueprints approved in Juno =========================== For specs approved in Juno, there is a fast track approval process for Kilo. The steps to get your spec re-approved are: - Copy your spec from the specs/juno/approved directory to the specs/kilo/approved directory. Note that if we declared your spec to be a "partial" implementation in Juno, it might be in the implemented directory. This was rare however. - Update the spec to match the new template - Commit, with the "Previously-approved: juno" commit message tag - Upload using git review as normal Reviewers will still do a full review of the spec, we are not offering a rubber stamp of previously approved specs. However, we are requiring only one +2 to merge these previously approved specs, so the process should be a lot faster. A note for core reviewers here -- please include a short note on why you're doing a single +2 approval on the spec so future generations remember…