Windisch Wide Web

My candidacy for the OpenStack Foundation Board

2012-08-20

The elections have started! If you’re eligable to vote, you should have already received an email containing a link to make your vote.

You can vote for one or many candidates, but the fewer candidates you vote for, the stronger your support.

I’m running. I’m not only running because it would be an interesting thing to do, or because I believe in the mission, but I really believe I can be a valuable asset to the Board. Not only have I been a long-standing contributor to Openstack, I have a background in business and brand ownership/management, event management, and pro se trademark / copyright law.

If I may have your support, it would be graciously appeciated, both in the elections and by word of mouth, too.

About Eric Windisch

Eric has a decade of experience in building web hosting and billing automation, and has been automating virtualization and storage since 2006. Currently with Cloudscaling, his previous position was as founder and operator of a small hosting/cloud services provider where he was involved in the management and legal affairs of business processes, trademarks, and copyrights. He has been a user of OpenStack since Austin and a contributor since Cactus. Furthermore, he has been a champion of open processes and transparency for OpenStack, both on and off the mailing lists.

What is your relationship to OpenStack, and why is its success important to you and/or your company? What would you say is your biggest contribution to OpenStack’s success to date?

Years before OpenStack entered the picture, I operated a small hosting operation where I felt our long-term success pinned on an open cloud solution. Today, while I’m no longer the owner/operator of a hosting firm, I remain resolved to help others build cloud computing solutions on open technologies. I became a contributor to OpenStack and joined Cloudscaling to achieve these personal goals.

My employer, Cloudscaling, is also vested in Openstack with it being the core foundation on which their product stands.

Describe your experience with other non profits or serving as a board member. How does your experience prepare you for the role of a board member?

I have nearly 10 years of experience operating a for-profit business. While I understand that non-profits are laden with many rules, regulations, and other differences to for-profits, I hope that many of my skills will transfer. For example, I already have experience in the registration and protection of trademarks, event and brand management, and as a developer myself, will be suited to understanding and emplowering develoepr needs.

What do you see as the Board’s role in OpenStack’s success?

The Board is essential to seeing that the growth and continues success of the community. Businesses need amiable terms for use of trademarks, copyrights, and a strong brand for OpenStack. Besides interesting puzzles, contributors are attracted and retained by a strong and healthy community online and off-line. The Board must see that contributor needs are met, that the community is maintained and strengthed, that each contributor’s voice is heard.

What do you think the top priority of the Board should be during the OpenStack Foundation’s first year?

I believe it is important not to make too many changes too quickly. However, there are serious problems with the current trademark agreements that must be resolved in due haste. I know that trademarks are not very exciting, but they’re very important to the adoption and use of OpenStack.

For example, the policy only allows commercial use of the trademark per written agreement. The standard written agreement requires that all products “Built for OpenStack” pass a FITS test, but this test does not exist. The PPB was responsible to provide a solution to the community by January 1st, 2012, but this has remained incomplete and undefined. The newly elected board will need to seek the creation of a FITS test or eliminate this requirement.

RPC Guarantees in OpenStack

2012-07-06

OpenStack RPC Guarantees

Here, we describe the required guarantees of OpenStack RPC implementations.

The statements made here are made through logical analysis and hypothesis. Experiments have not been conducted. I might have made mistakes, I welcome critism through the comments… and better yet, I welcome proof that anything I say here is wrong (or right!)

Missing Messages

OpenStack utilizes two messaging primitives, CAST and CALL. A CAST is sent and is not expected to return a value; the message is sent out into the ether and will succeed or fail. A CALL message is more complex, and a reply is expected.

A CALL is received by the RPC driver, a message is sent, and the RPC driver blocks until it returns. As messaging occurs asynchronously, the blocking is entirely performed on the client/publisher. If the thread is blocked too long, and no reply is received, a Timeout Exception is raised. If the remote CALL generates an Exception, it is serialized over the wire and re-raised by the RPC driver, back to the CALLER. Each caller is responsible for properly handling any Exception that might be raised.

Service Availability

It is necessary to expect failure. Drivers should always attempt to reconnect to their broker and/or peers. Messages destined for any consumer/worker are superfluous if they cannot be delivered within a reasonable time frame. This applies to both CAST and CALL. A timeout is set globally and can be manipulated per-message to adjust the TTL of messages. Best efforts to ensure delivery should be made, until the expiration of the TTL. If delivery fails, a Timeout Exception should be raised. Atomic actions and Idempotency

The RPC driver does not seem to be the place to implement atomic actions. The RPC drivers should simply raise Exceptions; idempotency and/or atomic-operations should be performed by the caller.

Surviving Restarts / Durability

If a publisher is sending a CALL or CAST, but the message has not been received by a consumer, upon restart of said consumer, that message should still be pending delivery until said consumer should consume that message; Except and unless said message has reached the expiration of its TTL, and the publisher has received a Timeout Exception. Failing to implement such TTLs is dangerous. For example, instance launches that cannot be succeed due to a failure of nova-scheduler should not be queued until the return of the scheduler (beyond a reasonable timeout), as this will inhibit the operation of autoscaling applications which may continuously attempt to launch new machine images. Currently, the AMQP-based drivers in OpenStack do not sufficiently support this TTL mechanism.

If a publisher attempts to send a CAST, but the message has not been received by a consumer, upon restart of the publisher, attempts to deliver said message should continue upon restoration of the publisher process. Alternatively, messages may be independently queued and guaranteed delivery by a third-party, as in the case of a centralized AMQP broker. The ZeroMQ driver does not currently provide this guarantee.

If a publisher attempts to send a CALL, but the message has not been received by a consumer, upon restart of the publisher, it is recommended that no attempts to deliver said message should be made upon restoration of the publisher process. This is because the purpose of the CALL was either to receive a return value from the consumer, or to block in a chain of events to prevent a race-condition. In the former, the return value of the call will be lost, as the state of the publisher has been discarded and the operational stack no longer exists. In the latter case, the chain of events will be broken, regardless, due to the loss of state and stack. Those looking for better guarantees should utilize an event-actor based model around CAST. While supporting a guarantee here is not recommended, it does not appear to be particularly dangerous. Instead, it is unnecessary and inefficient. Currently, the AMQP implementations in OpenStack guarantee delivery of a CALL, even if the publisher has expired.

Conclusion

RPC in OpenStack is doing fairly well, but it could do better. This applies to the ZeroMQ, Qpid, and RabbitMQ drivers. Hopefully, having documents/blogs like this will help drive improvements and innovations in these drivers, and assist those that might seek to write a new driver.

OpenStack Nova Distributed RPC with Zeromq

2012-04-18

I just gave this speech at the OpenStack design summit. We lost the original audio, so this is a fresh voice-over against the slide deck.

A new blog

2012-02-06

I’m no longer with GrokThis.net and am now with Cloudscaling, architecting cloud computing solutions.

This was a bold step for me, which I actually embarked upon a full year ago. Yet, until this month, I maintained my connections to GrokThis.net, not necessarily as a safety-net, but because I knew it had to be transferred or shutdown correctly. It pains me to say that the ultimate decision was to terminate services rather than transfer them. However, it seemed the right thing to do, if possibly controversial. (Certainly, many would have preferred we sold, and we could have)

It seems ironic to associate employment versus business ownership as a new-found freedom, but it feels this way. Business ownership is a weight on one’s soul, one’s life, and their family. I’m planning to exercise this freedom by getting to better understand some the providers which were once competitors. I need that perspective. I’ll be blogging about some of the things I’ve seen along the way in running my business, trends I see happening, and so forth.

If I say things that sound stupid, they might be, but I’ve found that most often, I’m just well ahead of the curve (GrokThis was)… but I’ll explain that in more detail, later.