Reflections on the first #OpenStack PTG (Pike PTG, Atlanta)

A very long time ago, and on a planet very unlike the earth we are on now, Thierry sent this email [1] proposing that after Barcelona, let’s split the OpenStack Summit into what have now come to be known as the Design Summit and a Forum. The email thread that resulted from [1] was an active one and had 125 responses, along the way Thierry also posted [2], a summary of the issues and concerns raised.

I had my reservations about the idea, and now, after returning from the first of these, have had some time to reflect on the result.

On the whole, the event was very well done, and I believe that everyone who attended the feedback session had positive things to say about the event, and my congratulations to Erin Disney and the rest of the team at the Foundation. The attendance was a solid 500 to 600 people (I don’t know the exact number) and Thierry must be psychic because he predicted almost exactly that in February [3].

pike-coffeeI did not realize that the foundation had gone as far as to get Starbucks to customize a blend of coffee for us, and to get the Sheraton to distribute in our rooms (image courtesy of Masayuki Igawa, @masayukig).

The format gave attendees the opportunity to get a significant amount of work done both within their own project teams, as well as with other project teams, without the interruptions and distractions of the summit.

I particularly liked the fact that I could attend two days of cross project sessions and then two and a half days of sessions with other projects. By giving projects two or three room-days instead of four or five room-hours dramatically improved the amount of time that projects could focus on their own discussions, and spend on cross project discussions.

Personally, I think the PTG was a success, and seems to have delivered most if not all of the things that it set out to do. Some things outside of our control, certainly outside the control of the foundation have cast a small shadow on the proceedings and we need to seriously consider the consequences of where the next summit and PTG’s are. The location has implication for many attendees, and I think we should seriously consider having remote participation at future events.

From my recollection of the feedback session (unfortunately I don’t have a link to the etherpad, if someone has it, please post a comment with it) everyone had good things to say about the event as a whole. The consensus was that the food was good but cold sandwiches get boring after day 3, the air handlers were noisy, the rooms were too cold (or hot), the chairs were uncomfortable, and there was no soda. That feedback is consistent with organizing an event for 500 people in a hotel or convention facility anywhere in the world. And if that’s all that people could put down in the “needs improvement” section, the event was a huge success.

designateI think the award for the best picture at the summit (thanks to Thierry for the tweet) goes to the Designate team[4]. I should’ve thought to get a Trove team photo while we were there!





Stratoscale acquires Tesora

Yesterday it was announced that Tesora had been acquired by Stratoscale, here are some of the articles that were published about this.

and this official announcement by Stratoscale

Thanks to all of you who emailed, texted, tweeted, called, and pinged me on IRC 🙂 I’m overwhelmed by the volume and all the good wishes. I’ll reply to each of you individually, sorry it may take a couple of days for me to do that.

To all of our investors and advisors, first in ParElastic and later in Tesora, thank you all for your help and support. To everyone at Tesora who is moving to Stratoscale, all the very best to you. It has truly been a wonderful six years working with you and I thoroughly enjoyed it.

Doug: It’s been especially awesome working with you these past six years. You are a great leader of people, and you have built and managed a truly exceptional team. People in your team like you, respect you, are comfortable approaching you with the strangest questions, and are willing to work with you over and over again. Not an easy thing to pull off over the extraordinarily long period that you’ve been able to do this. You were clearly not an easy taskmaster and your team consistently delivered miracles. But along the way you managed to ensure that everyone was having a good time.

Ken: No entrepreneur can have hoped for a better partner than you. It has been an extraordinary ride and it has been truly my honor and privilege to have taken this ride along with you. I think you were instrumental in building a company which was a very special place to work, where we built some excellent technology, got some marquee customers, and had a lot of fun doing it. I’ve learned a lot, about startups, about technology, about business, and about myself; thank you very much for this awesome experience.

Several of you have asked me “what’s next for Amrith”. I don’t know yet, I’m trying to figure that out (thanks to all of you who have offered to help me figure this out, I will certainly take you up on that).

In the short term, I’m going to continue to work on Trove, finish up my term as the PTL for Ocata and continue to work on the project as we begin the Pike cycle.

What comes later, I have no idea but if you have ideas, I’m all ears.

The Acurite SmartHub and monitoring solution

I purchased an Acurite 10 sensor indoor humidity and temperature monitoring system and am surprisingly happy with it. I was expecting a generally crappy experience but I have to say I was wrong, and it wasn’t that I’d set my expectations so low; the system is truly quite good.

The system I purchased is this one.

You get a smartHub and 10 sensors. Pictured below is the hub and a sensor.

06044-800x800_2_2 09150rm-phone-800x800_7

The setup: smartHub

The smartHub comes with a little power adapter and an ethernet cable. Stick it into a wall outlet and connect the ethernet cable to your router and DHCP does its thing and the smartHub gets online.

It initiates a series of accesses to some locations and downloads firmware and the like. (I’ve captured network traces, if I find anything interesting, I’ll blog about that). In a couple of minutes the lights stabilize and you have to press a button that says “Activate”.

The setup: online

Then you create an online account at the Acruite site and once you are logged in, you associate your account with the device. You identify it by the number on the bottom (spoiler alert, the number is the MAC address of the device).

Within about a minute, the device shows up and you are good to go for the next step.

The setup: sensors

Each sensor takes two AAA batteries, pop them in and within a minute the web portal shows a new device which you can rename and mount wherever you want it. Very slick and easy.

Within about 15 minutes I had 10 sensors online and reporting.

I was so happy with this that I’ve purchased another smartHub and 10 more indoor/outdoor sensors; they don’t have the LCD display.

Enough of the happy talk

OK, so what did I not like?

  1. It has been years (literally, years and years) since I’ve purchased a gadget that requires batteries, and the batteries are not included. It’s a good thing that I purchase AAA’s in packs of 50. Like every other commodity piece of electronics these days, these sensors are made in China, so just stick two AAA’s in the box please.
  2. Once you power up a sensor, it takes under a minute to initialize and register with the smartHub. But, if you stick batteries in two of them in quick succession, there’s no way to tell (on the Web UI) which is which. There’s no number on the sensor, nothing which you can associate with what you see on the screen; just “Temperature and Humidity Sensor – NN” where NN is a number incrementing from 1 to 10.
  3. Once you get sensors on the Web UI, there is no way to re-order them. The will forever remain in the same order. So if you decide to move a device from one location to another, and you want to group your devices based on location, you are not able to do that.
  4. Wired ethernet, really? I’m sure the stupid cable they have to give you will cost about as much as it would to get wireless setup. But it would make the setup just a bit harder.
  5. The web app is just about OK. Fine, it sucks. It allows you to add alerts for each device. By default, low battery and loss of signal rules are added for each device. But, I want to add temperature rules for different devices. Yes, you can do that but you get to do it one device at a time. No copy/paste available.
  6. They claim to have an android application but it won’t work on a tablet; instead they expect you to use a full blown web app for the tablet. The android app won’t install on my android phone; lots of others seem to be complaining about this as well.

Closing thoughts

Acurite strikes me as a company that makes fine hardware and they appear to have done an absolutely bang up job on the initial setup and “getting started” part of the experience.

They are not a software company. The software part of the “after setup” experience is kind of horrible.

They offer no easy API based mechanism to retrieve your sensor data. Yes, on the web app, you can click a couple of buttons and play with date controls and get a link to some AWS S3 bucket mailed to you with your data as a CSV but really, advertise an API, get someone to write an IFTTT channel, then you’ll be cooking with gas.

Next post will be a deconstruction of the protocol, what you get when you point your web browser at the smartHub’s IP address, and those kinds of fun things.

One more thing

The people at Acurite Support are wonderful. I have (in the past three days) spoken with two of them, and interacted with one via email. The people I spoke with were knowledgeable, and very helpful.

The wait times on hold are quite bad. I waited 25 minutes and 15 minutes respectively on hold. There is the usual boring elevator music while you stay in line with an announcement every minute that you are “XX in line”. No indication of how long your wait will be but you are offered the option of getting a callback.

An odd thing though is that while I was in line and I heard the message “you are second in line” a couple of times, I suddenly ended up being “third in line”. How someone got ahead of me in line, I know not.

But, their support is great. 5 stars for that!

Automating OpenStack’s gerrit commands with a CLI

Every OpenStack developer has to interact with the gerrit code review system. Reviewers and core reviewers have to do this even more, and PTL’s do a lot of this.

The web-based interface is not conducive to many of the more common things that one has to do while managing a project and early on, I started using the gerrit query CLI.

Along the way, I started writing a simple CLI that I could use to automate more things and recently a few people asked about these tools and whether I’d share.

I’m not claiming that this is unique, or that this hasn’t been done before; it evolved slowly and there may be a better set of tools out there that does all of this (and more). I don’t know about them. If you have similar tools, please do share (comment below).

So, I’ve cleaned up this tools a bit (removed things like my private key, username and password) and made them available here.

Full disclosure, they are kind of rough at the edges and you could cause yourself some grief if you aren’t quite sure what you are doing.

Here’s a quick introduction


It should be nothing more than cloning the repository and running the install command. Note, I use python 2.7 as my default python on Ubuntu 16.04. If you use python 3.x, your mileage may vary.

Simple commands

The simplest command is ‘ls’ to list reviews

gerrit-cli ls owner:self

As you can see, the search here is a standard gerrit query search.

You don’t have to type complex queries everytime, you can store and reuse queries. A very simple configuration file is used for this (a sample configuration file is also provided and gets installed by default).

amrith@amrith-work:~$ cat .gerrit-cli/gerrit-cli.json
    # global options
    "host": "",
    "port": 29418,

    # "dry-run": true,

    # user defined queries
    "queries": {
        # each query is necessarily a list, even if it is a single string
        "trove-filter": ["(project:openstack/trove-specs OR project:openstack/trove OR project:openstack/trove-dashboard OR project:openstack/python-troveclient OR project:openstack/trove-integration)"],

        # the simple filter uses the trove-filter and appends status:open and is therefore a list

        "simple": ["trove-filter", "status:open"],

        "review-list": ["trove-filter", "status:open", "NOT label:Code-Review>=-2,self"],

        "commitids": ["simple"],

        "older-than-two-weeks": ["simple", "age:2w"]

    # user defined results
    "results": {
        # each result is necessarily a list, even if it is a single column
        "default": ["number:r", "project:l", "owner:l", "subject:l:80", "state", "age:r"],
        "simple": ["number:r", "project:l", "owner:l", "subject:l:80", "state", "age:r"],
        "commitids": [ "number:r", "subject:l:60", "owner:l", "commitid:l", "patchset:r" ],
        "review-list": [ "number:r", "project:l", "branch:c", "subject:l:80", "owner:l", "state", "age:r" ]

The file is a simple JSON and you can comment lines just as you would in python (#…)

Don’t do anything, just – – dry-run

The best way to see what’s going on is to use the –dry-run command (or to be sure, uncomment the line in your configuration file).

amrith@amrith-work:~$ gerrit-cli --dry-run ls owner:self
ssh -p 29418 gerrit query --format=JSON --current-patch-set --patch-sets --all-approvals owner:self
| Number | Project | Owner | Subject | State | Age |

So the owner:self query makes a gerrit query and formats and displays the output as shown above.

So, what columns are displayed? The configuration contains a section called “results” and a default result is defined there.

"default": ["number:r", "project:l", "owner:l", "subject:l:80", "state", "age:r"],

You can override the default and cause a different set of columns to be shown. If a default is not found, the code has a hardcoded default as well.

Similarly, you could run the query:

amrith@amrith-work:~$ gerrit-cli --dry-run ls
ssh -p 29418 gerrit query --format=JSON --current-patch-set --patch-sets --all-approvals owner:self status:open
| Number | Project | Owner | Subject | State | Age |

and a default query will be generated for you, that query is owner:self and status:open.

You can nest these definitions as shown in the default configuration.

amrith@amrith-work:~$ gerrit-cli --dry-run ls commitids
ssh -p 29418 gerrit query --format=JSON --current-patch-set --patch-sets --all-approvals (project:openstack/trove-specs OR project:openstack/trove OR project:openstack/trove-dashboard OR project:openstack/python-troveclient OR project:openstack/trove-integration) status:open
| Number | Project | Owner | Subject | State | Age |

The query “commitids” is expanded as follows.

commitids -> simplesimple -> trove-filter, statusopentrove-filter -> (...)

What else can I do?

You can do a lot more than just list reviews …

amrith@amrith-work:~$ gerrit-cli --help
usage: gerrit [-h] [--host HOST] [--port PORT] [--dry-run]
              [--config-file CONFIG_FILE] [-v]
              {ls,show,update,abandon,restore,recheck} ...

A simple gerrit command line interface

positional arguments:
    ls                  list reviews
    show                show review(s)
    update              update review(s)
    abandon             abandon review(s)
    restore             restore review(s)
    recheck             abandon review(s)

optional arguments:
  -h, --help            show this help message and exit
  --host HOST           The gerrit host. Default:
  --port PORT           The gerrit port. Default: 29418
  --dry-run             Whether or not to actually execute commands that
                        modify a review.
  --config-file CONFIG_FILE
                        The path to the gerrit-cli configuration file to use
                        for this session. (Default: ~/.gerrit-cli/gerrit-
  -v, --verbose         Provide additional (verbose) debug output.

Other things that I do quite often (and like to automate) are update, abandon, restore and recheck.

A word of caution: when you aren’t sure what the command will do, use –dry-run. Otherwise, you could end up in a world of hurt.

Like, when you accidentally abandon a 100 reviews 🙂

And even if you know what your query should do, remember I’ve hidden some choice bugs in the code. You may hit those too.


I’ll update the readme with more information when I get some time.

Effective OpenStack contribution: Seven things to avoid at all cost

There are numerous blogs and resources for the new and aspiring OpenStack contributor, providing tips, listing what to do. Here are seven things to avoid if you want to be an effective OpenStack contributor.

I wrote one of these.

There have been presentations at summits that share other useful newbie tips as well, here is one.

Project repositories often include a CONTRIBUTING.rst file that shares information for newcomers. Here is the file for the Trove project.

Finally, many of these resources include a pointer to the OpenStack Developer’s Guide.

Over the past three years, I have seen several newbie mistakes repeated over and over again and in thinking about some recent incidents, I think the community has not done a good job documenting these “Don’t Do’s”.Just don't do it!

So here is a start; here are seven things you shouldn’t do, if you want to be an effective OpenStack contributor.

1. Don’t submit empty commit messages

captureThe commit message is a useful part of the commit and it serves to inform reviewers about what the change is, and how your proposed fix addresses the problem. In general, (with the notable exception of procedural commits for things like releases or infrastructure), the commit message should not be empty. The words “Trivial Fix” do not suffice.

OpenStack documents best practices for commit messages. Make sure your commit message provides a succinct description of the problem, describes how you propose to fix it, and includes a reference (via the Close-Bug, Partial-Bug or Related-Bug tags) to the Launchpad entry for the issue you are fixing.

2. Don’t expect that reviews are automatic

In OpenStack, reviewing changes is a community activity. If you propose changes, they get merged because others in the community contribute their time and effort in reviewing your changes. This wouldn’t work unless everyone participates in the review process.

Just because you submitted some changes, don’t expect others to feel motivated or obligated to review your changes. In many projects, review bandwidth is at a premium and therefore you will have a better chance getting your change reviewed and approved if you reciprocate and review other people’s changes.

3. Don’t leave empty reviews

captureWhen you review someone’s code, merely adding a +1 serves no useful purpose. At the very least indicate what you did with the change. Equally useful is to say what you did not do.

For example, you could indicate that you only reviewed the code and did not actually test it out. Or you could go further and download and test the patch set and indicate in your review comment that you tested the change and found it to work. On occasion, such as when I review a change for the first time, I will indicate that I have reviewed the changes but not the tests.

Feel free to ask questions about the change if you don’t follow what is being done. Also, feel free to suggest alternate implementations if you feel that the proposed implementation is not the best one for some reason(s).

Don’t feel shy about marking changes with a -1 if you feel that it is not ready to merge for some reason.

A drive-by +1 is a generally unhelpful activity, and if you persist at doing that, others in the community will tend to discount your reviews anyway.

4. Don’t game the Stackalytics system

captureBy far, the most egregious violation that I’ve seen is when people blatantly try to game the Stackalytics system. Stackalytics is a tool that tracks individual and company participation in OpenStack.

Here, for example, is the Stackalytics page for the Trove project in the current release:



It allows you to see many metrics in a graphical way, and allows you to slice and dice the data in a number of interesting ways.

New contributors, bubbling with enthusiasm often fall into the trap of trying to game the system and rack up reviews or commits. This can end up very badly for you if you go down this route. For example, recently one very enthusiastic person showed up with a change that got blasted out to about 150 projects, and attempted to add a CONTRIBUTING.rst file to all of these projects. What ensued is documented in this mailing list thread:

A few of the changes were merged before they were reverted, the vast majority were abandoned.

Changes like this serve no real useful purpose. They also consume an inordinate amount of resources in the CI system. I computed that the little shenanigan described above generated approximately 1050 CI jobs and consumed about 190 hours of time on the CI system.

I admit that numbers are important and they are a good indication of participation. But quality is a much more important metric because quality is an indicator of contribution. And I firmly believe that participation is about showing up, contribution is about what you do once you are here, and contribution is a way more important thing to aim for than participation.

5. Don’t ignore review comments

Finally, when you’ve submitted a change, and people review and provide comments, don’t ignore them. If you are serious about a change, you will stay with it till it gets merged. Respond to comments in a timely manner, if only to say that you will come back with a new patch set in some time.

If you don’t, remember that review bandwidth is a scarce resource and in the future your changes may get scant attention from reviewers. Others who review your changes are taking time out of their schedules to participate in the community. At the very least you should recognize and respect that investment on their part and reciprocate with timely responses.

6. Don’t be shy

And above all, if you aren’t sure how to proceed, don’t be shy. Post a question on the mailing list if you aren’t sure what to do about something. If that’s too public for you (and that’s perfectly alright), ask the question on the IRC channel for the project in question. If that is too public, find someone who is active on the project (start with the PTL) and send that person an email.

An important aspect of the role of a PTL is fielding those questions, and all of us (PTL’s) receive several of these questions each month. Not sure whom to ask, then toss the question out on IRC at #openstack or #openstack-dev and you should receive an answer before long.

7. Don’t be an IRC ghost

ghost_single-15An important thing to remember about IRC is that it is an asynchronous medium. So, don’t expect answers in real time. The OpenStack community is highly distributed, but also most active during daylight hours, Monday to Friday in US time. If you pop up on IRC, ask a question and then disappear, you may not get your answer. If you can’t stick around for a long time on IRC, then post your question to the mailing list.

But better still, there are many ways in which you can connect to IRC and leave the connection up (so you can read the scrollback), or find some other mechanism to review the scrollback (like to see if your question was answered.

If you have your own pet peeve, please share it in the comments section. I hope this will become a useful resource for aspiring OpenStack contributors.

Addressing a common misconception regarding OpenStack Trove security

Since my first OpenStack Summit in Atlanta (mid 2014), I have been to a number of OpenStack-related events, meetups, and summits. And at every one of these events, as well as numerous customer and prospect meetings, I’ve been asked some variant of the question:

Isn’t Trove insecure because the guestagent has RabbitMQ credentials?

A bug was entered in 2015 with the ominous (and factually inaccurate) description that reads “Guestagent config leaks rabbit password”.

And while I’ve tried to explain to people that this is not at all the case, this misconception has persisted.

At the Summit in Barcelona, I was asked yet again about this and I realized that obviously, whatever we in the Trove team had been doing to communicate the reality was insufficient. So, in preparation for the upcoming Summit in Boston, I’m writing this post as a handy resource.

What is the problem?

Shown here is a simplified representation of a Trove system with a single guest database instance. The control plane components (Trove API, Trove Task Manager, and Trove Conductor) and the Guest Agent communicate via oslo.messaging which is typically implemented with some messaging transport like RabbitMQ.

rpc-security-1To connect to the underlying transport, each of these four components needs to store credentials; for RabbitMQ this is a username and password.

The contention is that if a guest instance is somehow compromised (and there are many ways to do this) and a bad actor gains access to the RabbitMQ credentials, then the OpenStack deployment is compromised.

Why is this not really a problem?

Here are some reasons this is not really an issue on a properly configured production system.

  1. Nothing requires that Trove use the same RabbitMQ servers as the rest of OpenStack. So at the very least, the compromise can be limited to the RabbitMQ servers used by Trove.
  2. The guest instance is not intended to be a general-purpose instance that a user has access to; in the intended deployment, the only connectivity to the guest instance would be to the database ports for queries. These are configurable with each database (datastore) and enforced by Neutron. Shell access (port 22, ssh) is a no-no. No deployer would use images and configurations that allowed this kind of access.
  3. On the guest instance, other database specific best practices are used to prevent shell escapes and other exploits that will give a user access to the RabbitMQ credentials.
  4. Guest instances can be spawned by Trove using service credentials, or credentials for a shadow tenant to prevent an end user from directly accessing the underlying Nova instance. Similarly Cinder volumes can be provisioned with a different tenant to prevent an end user from directly accessing the underlying volume.

All of this notwithstanding, the urban legend was that Trove was a security risk. The reason invariably involved a system configured by devstack, with a single RabbitMQ, open access to port 22 on the guest, run in the same tenant as the requestor of the database.

Yet, one can safely say that no one in their right mind would operate OpenStack as configured by devstack in production. And certainly, with Trove, one would not use the development images whose elements are part of the source tree in a production deployment.

proposed security related improvements in Ocata

In the Ocata release, one additional set of changes has been made to further secure the system. All RPC calls on the oslo.messaging bus are completely encrypted. Furthermore, different conversations are encrypted using unique encryption keys.

rpc-security-2The messaging traffic on oslo.messaging is solely for oslo_messaging.rpc, the OpenStack Remote Procedure Call mechanism. The API service makes calls into the Task Manager, the Task Manager makes calls into the Guest Agent, and the Guest Agent makes calls into the Conductor.

The picture above shows these different conversations, and the encryption keys used on each. When the API service makes an RPC call to the Task Manager, all parameters to the call are encrypted using K1 which is stored securely on the control plane.

Unique encryption keys are created for each guest instance, and these keys are used for all communication. When the Task Manager wishes to make a call to Guest Agent 1, it uses the instance specific key K2, and when it wants to make a call to Guest Agent 2, it uses the instance specific key K3. When the guest agents want to make calls to the Conductor, the traffic is encrypted using the instance specific keys and the conductor decrypts the parameters using those instance specific keys.

In a well configured production deployment, one that takes steps to secure the system, if a bad actor were to compromise a guest instance (say Guest Agent 1) and get access to K2 and the RabbitMQ Credentials, the user could access RabbitMQ but would not be able to do anything to impact either another guest instance (he wouldn’t have K3) or the Task Manager (he wouldn’t have K1).

Code that implements this capability is currently in upstream review.

This blog post resulted in a brief twitter exchange with Adam Young (@admiyoung)

Unfortunately, a single user (in RabbitMQ) for Trove isn’t the answer. Should a guest get compromised, then those credentials are sufficient to post messages to RabbitMQ and cause some amount of damage.

One would need per guest instance credentials to avoid this; or one of the many other solutions (like shadow tenants, etc).

Amazon’s demented plans for its warehouse blimp with drone fleet 

Amazon’s demented plans for its warehouse blimp with drone fleet

Shit like this is what gives patents a bad name!