Made by Mikal – Page 33

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…

Lock In

Post author:mikal
Post published:October 9, 2014
Post category:Book

I know I like Scalzi stuff, but each series is so different that I like them all in different ways. I don't think he's written a murder mystery before, and this book was just as good as Old Man's War, which is a pretty high bar. This book revolves around a murder being investigated by someone who can only interact with the real world via personal androids. Its different from anything else I've seen, and a unique idea is pretty rare these days. Highly recommended.

On layers

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

There's been a lot of talk recently about what we should include in OpenStack and what is out of scope. This is interesting, in that many of us used to believe that we should do ''everything''. I think what's changed is that we're learning that solving all the problems in the world is hard, and that we need to re-focus on our core products. In this post I want to talk through the various "layers" proposals that have been made in the last month or so. Layers don't directly address what we should include in OpenStack or not, but they are a useful mechanism for trying to break up OpenStack into simpler to examine chunks, and I think that makes them useful in their own right. I would address what I believe the scope of the OpenStack project should be, but I feel that it makes this post so long that no one will ever actually read it. Instead, I'll cover that in a later post in this series. For now, let's explore what people are proposing as a layering model for OpenStack. What are layers? Dean Troyer did a good job of describing a layers model for the OpenStack…

Blueprints implemented in Nova during Juno

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

As we get closer to releasing the RC1 of Nova for Juno, I've started collecting a list of all the blueprints we implemented in Juno. This was mostly done because it helps me write the release notes, but I am posting it here because I am sure that others will find it handy too. Process Reserve 10 sql schema version numbers for back ports of Juno migrations to Icehouse. launchpad specification Ongoing behind the scenes work Object conversion Convert the compute manager to use nova objects. launchpad specification Convert EC2 API to use nova objects. launchpad specification Start converting hypervisor drivers to use objects. launchpad specification Scheduler Support sub-classing objects. launchpad specification Stop using the scheduler run_instance method. Previously the scheduler would select a host, and then boot the instance. Instead, let the scheduler select hosts, but then return those so the caller boots the instance. This will make it easier to move the scheduler to being a generic service instead of being internal to nova. launchpad specification Refactor the nova scheduler into being a library. This will make splitting the scheduler out into its own service later easier. launchpad specification Move nova to using the v2 cinder API. launchpad…

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

My candidacy for Kilo Compute PTL

Post author:mikal
Post published:September 30, 2014
Post category:OpenStack

This is mostly historical at this point, but I forgot to post it here when I emailed it a week or so ago. So, for future reference: I'd like another term as Compute PTL, if you'll have me. We live in interesting times. openstack has clearly gained a large amount of mind share in the open cloud marketplace, with Nova being a very commonly deployed component. Yet, we don't have a fantastic container solution, which is our biggest feature gap at this point. Worse -- we have a code base with a huge number of bugs filed against it, an unreliable gate because of subtle bugs in our code and interactions with other openstack code, and have a continued need to add features to stay relevant. These are hard problems to solve. Interestingly, I think the solution to these problems calls for a social approach, much like I argued for in my Juno PTL candidacy email. The problems we face aren't purely technical -- we need to work out how to pay down our technical debt without blocking all new features. We also need to ask for understanding and patience from those feature authors as we try and improve the…

The Decline and Fall of IBM: End of an American Icon?

Post author:mikal
Post published:September 27, 2014
Post category:Book

This book is quite readable, which surprises me for the relatively dry topic. Whilst obviously not everyone will agree with the author's thesis, it is clear that IBM hasn't been managed for long term success in a long time and there are a lot of very unhappy employees. The book is an interesting perspective on a complicated problem.

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…