nova – Page 2 – Made by Mikal

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…

Chronological list of Juno Nova mid-cycle meetup posts

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

This is a just a quick list of the posts I wrote summarizing the Juno Nova mid-cycle meetup in the right order to read them, because I didn't actually have that online before. I needed to send this list to someone, so I figured its easier to just post it here. Juno nova mid-cycle meetup summary: social issues Juno nova mid-cycle meetup summary: containers Juno nova mid-cycle meetup summary: ironic Juno nova mid-cycle meetup summary: DB2 support Juno nova mid-cycle meetup summary: cells Juno nova mid-cycle meetup summary: scheduler Juno nova mid-cycle meetup summary: slots Juno nova mid-cycle meetup summary: nova-network to Neutron migration Juno nova mid-cycle meetup summary: the next generation Nova API Juno nova mid-cycle meetup summary: conclusion

Juno nova mid-cycle meetup summary: conclusion

Post author:mikal
Post published:August 23, 2014
Post category:OpenStack

There's been a lot of content in this series about the Juno Nova mid-cycle meetup, so thanks to those who followed along with me. I've also received a lot of positive feedback about the posts, so I am thinking the exercise is worthwhile, and will try to be more organized for the next mid-cycle (and therefore get these posts out earlier). To recap quickly, here's what was covered in the series: The first post in the series covered social issues: things like how we organized the mid-cycle meetup, how we should address core reviewer burnout, and the current state of play of the Juno release. Bug management has been an ongoing issue for Nova for a while, so we talked about bug management. We are making progress on this issue, but more needs to be done and it's going to take a lot of help for everyone to get there. There was also discussion about proposals on how to handle review workload in the Kilo release, although nothing has been finalized yet. The second post covered the current state of play for containers in Nova, as well as our future direction. Unexpectedly, this was by far the most read post…

Juno nova mid-cycle meetup summary: the next generation Nova API

Post author:mikal
Post published:August 22, 2014
Post category:OpenStack

This is the final post in my series covering the highlights from the Juno Nova mid-cycle meetup. In this post I will cover our next generation API, which used to be called the v3 API but is largely now referred to as the v2.1 API. Getting to this point has been one of the more painful processes I think I've ever seen in Nova's development history, and I think we've learnt some important things about how large distributed projects operate along the way. My hope is that we remember these lessons next time we hit something as contentious as our API re-write has been. Now on to the API itself. It started out as an attempt to improve our current API to be more maintainable and less confusing to our users. We deliberately decided that we would not focus on adding features, but instead attempt to reduce as much technical debt as possible. This development effort went on for about a year before we realized we'd made a mistake. The mistake we made is that we assumed that our users would agree it was trivial to move to a new API, and that they'd do that even if there weren't…

Juno nova mid-cycle meetup summary: nova-network to Neutron migration

Post author:mikal
Post published:August 21, 2014
Post category:OpenStack

This will be my second last post about the Juno Nova mid-cycle meetup, which covers the state of play for work on the nova-network to Neutron upgrade. First off, some background information. Neutron (formerly Quantum) was developed over a long period of time to replace nova-network, and added to the OpenStack Folsom release. The development of new features for nova-network was frozen in the Nova code base, so that users would transition to Neutron. Unfortunately the transition period took longer than expected. We ended up having to unfreeze development of nova-network, in order to fix reliability problems that were affecting our CI gating and the reliability of deployments for existing nova-network users. Also, at least two OpenStack companies were carrying significant feature patches for nova-network, which we wanted to merge into the main code base. You can see the announcement at http://lists.openstack.org/pipermail/openstack-dev/2014-January/025824.html. The main enhancements post-freeze were a conversion to use our new objects infrastructure (and therefore conductor), as well as features that were being developed by Nebula. I can't find any contributions from the other OpenStack company in the code base at this time, so I assume they haven't been proposed. The nova-network to Neutron migration path has come…

Juno nova mid-cycle meetup summary: slots

Post author:mikal
Post published:August 20, 2014
Post category:OpenStack

If I had to guess what would be a controversial topic from the mid-cycle meetup, it would have to be this slots proposal. I was actually in a Technical Committee meeting when this proposal was first made, but I'm told there were plenty of people in the room keen to give this idea a try. Since the mid-cycle Joe Gordon has written up a more formal proposal, which can be found at https://review.openstack.org/#/c/112733. If you look at the last few Nova releases, core reviewers have been drowning under code reviews, so we need to control the review workload. What is currently happening is that everyone throws up their thing into Gerrit, and then each core tries to identify the important things and review them. There is a list of prioritized blueprints in Launchpad, but it is not used much as a way of determining what to review. The result of this is that there are hundreds of reviews outstanding for Nova (500 when I wrote this post). Many of these will get a review, but it is hard for authors to get two cores to pay attention to a review long enough for it to be approved and merged. If…

Juno nova mid-cycle meetup summary: scheduler

Post author:mikal
Post published:August 19, 2014
Post category:OpenStack

This post is in a series covering the discussions at the Juno Nova mid-cycle meetup. This post will cover the current state of play of our scheduler refactoring efforts. The scheduler refactor has been running for a fair while now, dating back to at least the Hong Kong summit (so about 1.5 release cycles ago). The original intent of the scheduler sub-team's effort was to pull the scheduling code out of Nova so that it could be rapidly iterated on its own, with the eventual goal being to support a single scheduler across the various OpenStack services. For example, the scheduler that makes placement decisions about your instances could also be making decisions about the placement of your storage resources and could therefore ensure that they are co-located as much as possible. During this process we realized that a big bang replacement is actually much harder than we thought, and the plan has morphed into being a multi-phase effort. The first step is to make the interface for the scheduler more clearly defined inside the Nova code base. For example, in previous releases, it was the scheduler that launched instances: the API would ask the scheduler to find available hypervisor…

Juno nova mid-cycle meetup summary: bug management

Post author:mikal
Post published:August 18, 2014
Post category:OpenStack

Welcome to the next exciting installment of the Nova Juno mid-cycle meetup summary. In the previous chapter, our hero battled a partially complete cells implementation, by using his +2 smile of good intentions. In this next exciting chapter, watch him battle our seemingly never ending pile of bugs! Sorry, now that I'm on to my sixth post in this series I feel like it's time to get more adventurous in the introductions. For at least the last cycle, and probably longer, Nova has been struggling with the number of bugs filed in Launchpad. I don't think the problem is that Nova has terrible code, it is instead that we have a lot of users filing bugs, and the team working on triaging and closing bugs is small. The complexity of the deployment options with Nova make this problem worse, and that complexity increases as we allow new drivers for things like different storage engines to land in the code base. The increasing number of permutations possible with Nova configurations is a problem for our CI systems as well, as we don't cover all of these options and this sometimes leads us to discover that they don't work as expected in…

Juno nova mid-cycle meetup summary: cells

Post author:mikal
Post published:August 16, 2014
Post category:OpenStack

This is the next post summarizing the Juno Nova mid-cycle meetup. This post covers the cells functionality used by some deployments to scale Nova. For those unfamiliar with cells, it's a way of combining smaller Nova installations into a thing which feels like a single large Nova install. So for example, Rackspace deploys Nova in cells of hundreds of machines, and these cells form a Nova availability zone which might contain thousands of machines. The cells in one of these deployments form a tree: users talk to the top level of the tree, which might only contain API services. That cell then routes requests to child cells which can actually perform the operation requested. There are a few reasons why Rackspace does this. Firstly, it keeps the MySQL databases smaller, which can improve the performance of database operations and backups. Additionally, cells can contain different types of hardware, which are then partitioned logically. For example, OnMetal (Rackspace's Ironic-based baremetal product) instances come from a cell which contains OnMetal machines and only publishes OnMetal flavors to the parent cell. Cells was originally written by Rackspace to meet its deployment needs, but is now used by other sites as well. However, I…

Juno nova mid-cycle meetup summary: DB2 support

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

This post is one part of a series discussing the OpenStack Nova Juno mid-cycle meetup. It's a bit shorter than most of the others, because the next thing on my list to talk about is DB2, and that's relatively contained. IBM is interested in adding DB2 support as a SQL database for Nova. Theoretically, this is a relatively simple thing to do because we use SQLAlchemy to abstract away the specifics of the SQL engine. However, in reality, the abstraction is leaky. The obvious example in this case is that DB2 has different rules for foreign keys than other SQL engines we've used. So, in order to be able to make this change, we need to tighten up our schema for the database. The change that was discussed is the requirement that the UUID column on the instances table be not null. This seems like a relatively obvious thing to allow, given that UUID is the official way to identify an instance, and has been for a really long time. However, there are a few things which make this complicated: we need to understand the state of databases that might have been through a long chain of upgrades from previous…