2015.02: State of the 'puck

44 views
Skip to first unread message

Casey Marshall

unread,
Feb 21, 2015, 1:53:15 PM2/21/15
to hockeypu...@googlegroups.com
Hey,
I'd like to revive this mailing list to engage with all of you interested in the Hockeypuck project. I really have no idea how many of you are deploying Hockeypuck, other than the individual emails I get from time-to-time. I get enough of them to stay motivated, and keep things rolling along as time permits :)

Hockeypuck 1.x is in a feature freeze, as I'm working on Hockeypuck 2.0 refactoring and new features. The roadmap for 2.0 is up here: https://github.com/hockeypuck/hockeypuck/wiki/Project-Status.

https://gopkg.in/hockeypuck/conflux.v2 is looking good. Seems much more stable and testable than before, and it's now tracked by Travis CI. I've just landed an ipv6 contribution from bjmgeek in v2 as well (thanks for that!).

Hockeypuck 2.0 is in progress -- I've just finished refactoring out the OpenPGP processing. It needs more test coverage, but at least it's decoupled from the rest of the service now -- it just handles packet processing -- parsing, deduplication, signature verification, revocation & expiration checking, SKS-style digests etc.

I'm currently working on the service side in https://github.com/cmars/hockeypuck/tree/v2-005-hkp-refactor. I've decided to remove HTML template processing from the core HKP handlers. Other than armored key material and machine-readable responses, the HKP core will respond with application/json in a Hockeypuck custom wire format (to be documented). Classic HTML responses can be supported by adding middleware to process the wire format types with html/templates of your own design. Or, a Javascript front-end can call the Hockeypuck APIs directly. I'm a horrible front-end web developer; best I can do is build a service friendly to those who are.

I'm about to start on the storage layer refactoring. I've gotten some interest in a Neo4j storage backend to support WoT analysis -- this will be a key enabler for that. I'm also considering other backends.

I'm also considering removing direct op=stats support from the core. I'd like to have Hockeypuck just spew metrics inline at StatsD instead, and let Carbon queries produce an op=stats response. In general, I'd like Hockeypuck to become a smaller, more reusable microservice -- and less of a kitchen sink.

-Casey
Reply all
Reply to author
Forward
0 new messages