Content here is by Michael Still mikal@stillhq.com. All opinions are my own.
See recent comments. RSS feed of all comments.


Juno nova mid-cycle meetup summary: DB2 support

    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 Nova releases, and we need to ensure that the schema alterations don't cause significant performance problems for existing large deployments.

    As an aside, people sometimes complain that Nova development is too slow these days, and they're probably right, because things like this slow us down. A relatively simple change to our database schema requires a whole bunch of performance testing and negotiation with operators to ensure that its not going to be a problem for people. It's good that we do these things, but sometimes it's hard to explain to people why forward progress is slow in these situations.

    Matt Riedemann from IBM has been doing a good job of handling this change. He's written a tool that operators can run before the change lands in Juno that checks if they have instance rows with null UUIDs. Additionally, the upgrade process has been well planned, and is documented in the specification available on the fancy pants new specs website.

    We had a long discussion about this change at the meetup, and how it would impact on large deployments. Both Rackspace and HP were asked if they could run performance tests to see if the schema change would be a problem for them. Unfortunately HP's testing hardware was tied up with another project, so we only got numbers from Rackspace. For them, the schema change took 42 minutes for a large database. Almost all of that was altering the column to be non-nullable; creating the new index was only 29 seconds of runtime. However, the Rackspace database is large because they don't currently purge deleted rows, if they can get that done before running this schema upgrade then the impact will be much smaller.

    So the recommendation here for operators is that it is best practice to purge deleted rows from your databases before an upgrade, especially when schema migrations need to occur at the same time. There are some other takeaways for operators as well: if we know that operators have a large deployment, then we can ask if an upgrade will be a problem. This is why being active on the openstack-operators mailing list is important. Additionally, if operators are willing to donate a dataset to Turbo-Hipster for DB CI testing, then we can use that in our automation to try and make sure these upgrades don't cause you pain in the future.

    In the next post in this series I'll talk about the future of cells, and the work that needs to be done there to make it a first class citizen.

    Tags for this post: openstack juno nova mid-cycle summary sql database sqlalchemy db2
    Related posts: Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion; Juno nova mid-cycle meetup summary: social issues; Juno nova mid-cycle meetup summary: scheduler; Juno nova mid-cycle meetup summary: containers

posted at: 19:20 | path: /openstack/juno | permanent link to this entry


Review priorities as we approach juno-3

    I just send this email out to openstack-dev, but I am posting it here in case it makes it more discoverable to people drowning in email:

    To: openstack-dev
    Subject: [nova] Review priorities as we approach juno-3
    
    Hi.
    
    We're rapidly approaching j-3, so I want to remind people of the
    current reviews that are high priority. The definition of high
    priority I am using here is blueprints that are marked high priority
    in launchpad that have outstanding code for review -- I am sure there
    are other reviews that are important as well, but I want us to try to
    land more blueprints than we have so far. These are listed in the
    order they appear in launchpad.
    
    == Compute Manager uses Objects (Juno Work) ==
    
    https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/compute-manager-objects-juno,n,z
    
    This is ongoing work, but if you're after some quick code review
    points they're very easy to review and help push the project forward
    in an important manner.
    
    == Move Virt Drivers to use Objects (Juno Work) ==
    
    I couldn't actually find any code out for review for this one apart
    from https://review.openstack.org/#/c/94477/, is there more out there?
    
    == Add a virt driver for Ironic ==
    
    This one is in progress, but we need to keep going at it or we wont
    get it merged in time.
    
    * https://review.openstack.org/#/c/111223/ was approved, but a rebased
    ate it. Should be quick to re-approve.
    * https://review.openstack.org/#/c/111423/
    * https://review.openstack.org/#/c/111425/
    * ...there are more reviews in this series, but I'd be super happy to
    see even a few reviewed
    
    == Create Scheduler Python Library ==
    
    * https://review.openstack.org/#/c/82778/
    * https://review.openstack.org/#/c/104556/
    
    (There are a few abandoned patches in this series, I think those two
    are the active ones but please correct me if I am wrong).
    
    == VMware: spawn refactor ==
    
    * https://review.openstack.org/#/c/104145/
    * https://review.openstack.org/#/c/104147/ (Dan Smith's -2 on this one
    seems procedural to me)
    * https://review.openstack.org/#/c/105738/
    * ...another chain with many more patches to review
    
    Thanks,
    Michael
    


    The actual email thread is at http://lists.openstack.org/pipermail/openstack-dev/2014-August/043098.html.

    Tags for this post: openstack juno review nova ptl
    Related posts: Thoughts from the PTL; Expectations of core reviewers; Juno nova mid-cycle meetup summary: social issues; Juno Nova PTL Candidacy; Juno nova mid-cycle meetup summary: slots; Juno nova mid-cycle meetup summary: nova-network to Neutron migration

posted at: 13:01 | path: /openstack/juno | permanent link to this entry


Juno nova mid-cycle meetup summary: ironic

    Welcome to the third in my set of posts covering discussion topics at the nova juno mid-cycle meetup. The series might never end to be honest.

    This post will cover the progress of the ironic nova driver. This driver is interesting as an example of a large contribution to the nova code base for a couple of reasons -- its an official OpenStack project instead of a vendor driver, which means we should already have well aligned goals. The driver has been written entirely using our development process, so its already been reviewed to OpenStack standards, instead of being a large code dump from a separate development process. Finally, its forced us to think through what merging a non-trivial code contribution should look like, and I think that formula will be useful for later similar efforts, the Docker driver for example.

    One of the sticking points with getting the ironic driver landed is exactly how upgrade for baremetal driver users will work. The nova team has been unwilling to just remove the baremetal driver, as we know that it has been deployed by at least a few OpenStack users -- the largest deployment I am aware of is over 1,000 machines. Now, this unfortunate because the baremetal driver was always intended to be experimental. I think what we've learnt from this is that any driver which merges into the nova code base has to be supported for a reasonable period of time -- nova isn't the right place for experiments. Now that we have the stackforge driver model I don't think that's too terrible, because people can iterate quickly in stackforge, and when they have something stable and supportable they can merge it into nova. This gives us the best of both worlds, while providing a strong signal to deployers about what the nova team is willing to support for long periods of time.

    The solution we came up with for upgrades from baremetal to ironic is that the deployer will upgrade to juno, and then run a script which converts their baremetal nodes to ironic nodes. This script is "off line" in the sense that we do not expect new baremetal nodes to be launchable during this process, nor after it is completed. All further launches would be via the ironic driver.

    These nodes that are upgraded to ironic will exist in a degraded state. We are not requiring ironic to support their full set of functionality on these nodes, just the bare minimum that baremetal did, which is listing instances, rebooting them, and deleting them. Launch is excluded for the reasoning described above.

    We have also asked the ironic team to help us provide a baremetal API extension which knows how to talk to ironic, but this was identified as a need fairly late in the cycle and I expect it to be a request for a feature freeze exception when the time comes.

    The current plan is to remove the baremetal driver in the Kilo release.

    Previously in this post I alluded to the review mechanism we're using for the ironic driver. What does that actually look like? Well, what we've done is ask the ironic team to propose the driver as a series of smallish (500 line) changes. These changes are broken up by functionality, for example the code to boot an instance might be in one of these changes. However, because of the complexity of splitting existing code up, we're not requiring a tempest pass on each step in the chain of reviews. We're instead only requiring this for the final member in the chain. This means that we're not compromising our CI requirements, while maximizing the readability of what would otherwise be a very large review. To stop the reviews from merging before we're comfortable with them, there's a marker review at the beginning of the chain which is currently -2'ed. When all the code is ready to go, I remove the -2 and approve that first review and they should all merge together.

    In the next post I'll cover the state of adding DB2 support to nova.

    Tags for this post: openstack juno nova mid-cycle summary ironic
    Related posts: Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion; Juno nova mid-cycle meetup summary: social issues; Juno nova mid-cycle meetup summary: scheduler; Juno nova mid-cycle meetup summary: containers

posted at: 01:49 | path: /openstack/juno | permanent link to this entry


Juno nova mid-cycle meetup summary: containers

    This is the second in my set of posts discussing the outcomes from the OpenStack nova juno mid-cycle meetup. I want to focus in this post on things related to container technologies.

    Nova has had container support for a while in the form of libvirt LXC. While it can be argued that this support isn't feature complete and needs more testing, its certainly been around for a while. There is renewed interest in testing libvirt LXC in the gate, and a team at Rackspace appears to be working on this as I write this. We have already seen patches from this team as they fix issues they find on the way. There are no plans to remove libvirt LXC from nova at this time.

    The plan going forward for LXC tempest testing is to add it as an experimental job, so that people reviewing libvirt changes can request the CI system to test LXC by using "check experimental". This hasn't been implemented yet, but will be advertised when it is ready. Once we've seen good stable results from this experimental check we will talk about promoting it to be a full blown check job in our CI system.

    We have also had prototype support for Docker for some time, and by all reports Eric Windisch has been doing good work at getting this driver into a good place since it moved to stackforge. We haven't started talking about specifics for when this driver will return to the nova code base, but I think at this stage we're talking about Kilo at the earliest. The driver has CI now (although its still working through stability issues to my understanding) and progresses well. I expect there to be a session at the Kilo summit in the nova track on the current state of this driver, and we'll decide whether to merge it back into nova then.

    There was also representation from the containers sub-team at the meetup, and they spent most of their time in a break out room coming up with a concrete proposal for what container support should look like going forward. The plan looks a bit like this:

    Nova will continue to support "lowest common denominator containers": by this I mean that things like the libvirt LXC and docker driver will be allowed to exist, and will expose the parts of containers that can be made to look like virtual machines. That is, a caller to the nova API should not need to know if they are interacting with a virtual machine or a container, it should be opaque to them as much as possible. There is some ongoing discussion about the minimum functionality we should expect from a hypervisor driver, so we can expect this minimum level of functionality to move over time.

    The containers sub-team will also write a separate service which exposes a more full featured container experience. This service will work by taking a nova instance UUID, and interacting with an agent within that instance to create containers and manage them. This is interesting because it is the first time that a compute project will have an in operating system agent, although other projects have had these for a while. There was also talk about the service being able to start an instance if the user didn't already have one, or being able to declare an existing instance to be "full" and then create a new one for the next incremental container. These are interesting design issues, and I'd like to see them explored more in a specification.

    This plan met with general approval within the room at the meetup, with the suggestion being that it move forward as a stackforge project as part of the compute program. I don't think much code has been implemented yet, but I hope to see something come of these plans soon. The first step here is to create some specifications for the containers service, which we will presumably create in the nova-specs repository for want of a better place.

    Thanks for reading my second post in this series. In the next post I will cover progress with the Ironic nova driver.

    Tags for this post: openstack juno nova mid-cycle summary containers docker lxc
    Related posts: Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion; Juno nova mid-cycle meetup summary: social issues; Juno nova mid-cycle meetup summary: scheduler; Juno nova mid-cycle meetup summary: ironic

posted at: 01:17 | path: /openstack/juno | permanent link to this entry


Wed, 13 Aug 2014



Juno nova mid-cycle meetup summary: social issues

    Summarizing three days of the Nova Juno mid-cycle meetup is a pretty hard thing to do - I'm going to give it a go, but just in case I miss things, there is an etherpad with notes from the meetup at https://etherpad.openstack.org/p/juno-nova-mid-cycle-meetup. I'm also going to do it in the form of a series of posts, so as to not hold up any content at all in the wait for perfection. This post covers the mechanics of each day at the meetup, reviewer burnout, and the Juno release.

    First off, some words about the mechanics of the meetup. The meetup was held in Beaverton, Oregon at an Intel campus. Many thanks to Intel for hosting the event -- it is much appreciated. We discussed possible locations and attendance for future mid-cycle meetups, and the consensus is that these events should "always" be in the US because that's where the vast majority of our developers are. We will consider other host countries when the mix of Nova developers change. Additionally, we talked about the expectations of attendance at these events. The Icehouse mid-cycle was an experiment, but now that we've run two of these I think they're clearly useful events. I want to be clear that we expect nova-drivers members to attend these events at all possible, and strongly prefer to have all nova-cores at the event.

    I understand that sometimes life gets in the way, but that's the general expectation. To assist with this, I am going to work on advertising these events much earlier than we have in the past to give time for people to get travel approval. If any core needs me to go to the Foundation and ask for travel assistance, please let me know.

    I think that co-locating the event with the Ironic and Containers teams helped us a lot this cycle too. We can't co-locate with every other team working on OpenStack, but I'd like to see us pick a couple of teams -- who we might be blocking -- each cycle and invite them to co-locate with us. It's easy at this point for Nova to become a blocker for other projects, and we need to be careful not to get in the way unless we absolutely need to.

    The process for each of the three days: we met at Intel at 9am, and started each day by trying to cherry pick the most important topics from our grab bag of items at the top of the etherpad. I feel this worked really well for us.

    Reviewer burnout

    We started off talking about core reviewer burnout, and what we expect from core. We've previously been clear that we expect a minimum level of reviews from cores, but we are increasingly concerned about keeping cores "on the same page". The consensus is that, at least, cores should be expected to attend summits. There is a strong preference for cores making it to the mid-cycle if at all possible. It was agreed that I will approach the OpenStack Foundation and request funding for cores who are experiencing budget constraints if needed. I was asked to communicate these thoughts on the openstack-dev mailing list. This openstack-dev mailing list thread is me completing that action item.

    The conversation also covered whether it was reasonable to make trivial updates to a patch that was close to being acceptable. For example, consider a patch which is ready to merge apart from its commit message needing a trivial tweak. It was agreed that it is reasonable for the second core reviewer to fix the commit message, upload a new version of the patch, and then approve that for merge. It is a good idea to leave a note in the review history about this when these cases occur.

    We expect cores to use their judgement about what is a trivial change.

    I have an action item to remind cores that this is acceptable behavior. I'm going to hold off on sending that email for a little bit because there are a couple of big conversations happening about Nova on openstack-dev. I don't want to drown people in email all at once.

    Juno release

    We also took at look at the Juno release, with j-3 rapidly approaching. One outcome was to try to find a way to focus reviewers on landing code that is a project priority. At the moment we signal priority with the priority field in the launchpad blueprint, which can be seen in action for j-3 here. However, high priority code often slips away because we currently let reviewers review whatever seems important to them.

    There was talk about picking project sponsored "themes" for each release -- with the obvious examples being "stability" and "features". One problem here is that we haven't had a lot of luck convincing developers and reviewers to actually work on things we've specified as project goals for a release. The focus needs to move past specific features important to reviewers. Contributors and reviewers need to spend time fixing bugs and reviewing priority code. The harsh reality is that this hasn't been a glowing success.

    One solution we're going to try is using more of the Nova weekly meeting to discuss the status of important blueprints. The meeting discussion should then be turned into a reminder on openstack-dev of the current important blueprints in need of review. The side effect of rearranging the weekly meeting is that we'll have less time for the current sub-team updates, but people seem ok with that.

    A few people have also suggested various interpretations of a "review day". One interpretation is a rotation through nova-core of reviewers who spend a week of their time reviewing blueprint work. I think these ideas have merit. An action item for me to call for volunteers to sign up for blueprint focused reviewing.

    Conclusion

    As I mentioned earlier, this is the first in a series of posts. In this post I've tried to cover social aspects of nova -- the mechanics of the Nova Juno mid-cycle meetup, and reviewer burnout - and our current position in the Juno release cycle. There was also discussion of how to manage our workload in Kilo, but I'll leave that for another post. It's already been alluded to on the openstack-dev mailing list this post and the subsequent proposal in gerrit. If you're dying to know more about what we talked about, don't forget the relatively comprehensive notes in our etherpad.

    Tags for this post: openstack juno nova mid-cycle summary core review social
    Related posts: Juno nova mid-cycle meetup summary: slots; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion; Juno nova mid-cycle meetup summary: scheduler; Juno nova mid-cycle meetup summary: containers

posted at: 23:57 | path: /openstack/juno | permanent link to this entry


Tue, 12 Aug 2014



More turning

posted at: 22:24 | path: /wood/turning/20140718-woodturning | permanent link to this entry


I've been making pens

posted at: 22:08 | path: /wood/turning/20140628-woodturning | permanent link to this entry


Expectations of core reviewers

    One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This blog post is an attempt at that.

    Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness.

    Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other.

    There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance.

    Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required.

    Tags for this post: openstack juno ptl nova
    Related posts: Thoughts from the PTL; Juno Nova PTL Candidacy; Review priorities as we approach juno-3; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion

posted at: 17:16 | path: /openstack/juno | permanent link to this entry


Sun, 10 Aug 2014



devpi as a pip cache

posted at: 19:58 | path: /openstack | permanent link to this entry


Wed, 02 Jul 2014



Interesting things found whilst surfing

posted at: 16:33 | path: /link | permanent link to this entry


Configuring a spa3000 or spa3102

posted at: 16:26 | path: /voip | permanent link to this entry


Tue, 10 Jun 2014



LCA2015 opens its Call for Proposals

posted at: 00:37 | path: /conference/lca2015 | permanent link to this entry


Mon, 09 Jun 2014



More wood turning

posted at: 21:28 | path: /wood/turning/20140610-woodturning | permanent link to this entry


Thu, 01 May 2014



A couple of days of turning

posted at: 21:01 | path: /wood/turning/20140502-woodturning | permanent link to this entry


Wed, 30 Apr 2014



Another bowl

posted at: 18:28 | path: /wood/turning/20140428-woodturning | permanent link to this entry


Tue, 15 Apr 2014



Juno TC Candidacy

    Another email archived for historical reasons.

    I'd also like to announce my TC candidacy. I am currently a member of
    the TC, and I would like to continue to serve.
    
    I first started hacking on Nova during the Diablo release, with my
    first code contributions appearing in the Essex release. Since then
    I've hacked mostly on Nova and Oslo, although I have also contributed
    to many other projects as my travels have required. For example, I've
    tried hard to keep various projects in sync with their imports of
    parts of Oslo I maintain.
    
    I work full time on OpenStack at Rackspace, leading a team of
    developers who work solely on upstream open source OpenStack. I am a
    Nova and Oslo core reviewer and the Nova PTL.
    
    I have been serving on the TC for the last year, and in the Icehouse
    release started acting as the liaison for the board "defcore"
    committee along with Anne Gentle. "defcore" is the board effort to
    define what parts of OpenStack we require vendors to ship in order to
    be able to use the OpenStack trade mark, so it involves both the board
    and the TC. That liaison relationship is very new and only starting to
    be effective now, so I'd like to keep working on that if you're
    willing to allow it.
    


    Tags for this post: openstack juno tc election
    Related posts: Juno Nova PTL Candidacy; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Thoughts from the PTL; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion; On layers

posted at: 00:01 | path: /openstack/juno | permanent link to this entry


Mon, 14 Apr 2014



Thoughts from the PTL

    I sent this through to the openstack-dev mailing list (you can see the thread here), but I want to put it here as well for people who don't actively follow the mailing list.

    First off, thanks for electing me as the Nova PTL for Juno. I find the
    outcome of the election both flattering and daunting. I'd like to
    thank Dan and John for running as PTL candidates as well -- I strongly
    believe that a solid democratic process is part of what makes
    OpenStack so successful, and that isn't possible without people being
    will to stand up during the election cycle.
    
    I'm hoping to send out regular emails to this list with my thoughts
    about our current position in the release process. Its early in the
    cycle, so the ideas here aren't fully formed yet -- however I'd rather
    get feedback early and often, in case I'm off on the wrong path. What
    am I thinking about at the moment? The following things:
    
    * a mid cycle meetup. I think the Icehouse meetup was a great success,
    and I'd like to see us do this again in Juno. I'd also like to get the
    location and venue nailed down as early as possible, so that people
    who have complex travel approval processes have a chance to get travel
    sorted out. I think its pretty much a foregone conclusion this meetup
    will be somewhere in the continental US. If you're interested in
    hosting a meetup in approximately August, please mail me privately so
    we can chat.
    
    * specs review. The new blueprint process is a work of genius, and I
    think its already working better than what we've had in previous
    releases. However, there are a lot of blueprints there in review, and
    we need to focus on making sure these get looked at sooner rather than
    later. I'd especially like to encourage operators to take a look at
    blueprints relevant to their interests. Phil Day from HP has been
    doing a really good job at this, and I'd like to see more of it.
    
    * I promised to look at mentoring newcomers. The first step there is
    working out how to identify what newcomers to mentor, and who mentors
    them. There's not a lot of point in mentoring someone who writes a
    single drive by patch, so working out who to invest in isn't as
    obvious as it might seem at first. Discussing this process for
    identifying mentoring targets is a good candidate for a summit
    session, so have a ponder. However, if you have ideas let's get
    talking about them now instead of waiting for the summit.
    
    * summit session proposals. The deadline for proposing summit sessions
    for Nova is April 20, which means we only have a little under a week
    to get that done. So, if you're sitting on a summit session proposal,
    now is the time to get it in.
    
    * business as usual. We also need to find the time for bug fix code
    review, blueprint implementation code review, bug triage and so forth.
    Personally, I'm going to focus on bug fix code review more than I have
    in the past. I'd like to see cores spend 50% of their code review time
    reviewing bug fixes, to make the Juno release as solid as possible.
    However, I don't intend to enforce that, its just me asking real nice.
    
    Thanks for taking the time to read this email, and please do let me
    know if you think this sort of communication is useful.
    


    Tags for this post: openstack juno ptl nova
    Related posts: Expectations of core reviewers; Juno Nova PTL Candidacy; Review priorities as we approach juno-3; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts; Juno nova mid-cycle meetup summary: conclusion

posted at: 00:01 | path: /openstack/juno | permanent link to this entry


Sat, 05 Apr 2014



Initial play with wood turning

posted at: 17:17 | path: /wood/turning/20140406-woodturning | permanent link to this entry


Sat, 29 Mar 2014



Juno Nova PTL Candidacy

    This is a repost of an email to the openstack-dev list, which is mostly here for historical reasons.

    Hi.
    
    I would like to run for the OpenStack Compute PTL position as well.
    
    I have been an active nova developer since late 2011, and have been a
    core reviewer for quite a while. I am currently serving on the
    Technical Committee, where I have recently been spending my time
    liaising with the board about how to define what software should be
    able to use the OpenStack trade mark. I've also served on the
    vulnerability management team, and as nova bug czar in the past.
    
    I have extensive experience running Open Source community groups,
    having served on the TC, been the Director for linux.conf.au 2013, as
    well as serving on the boards of various community groups over the
    years.
    
    In Icehouse I hired a team of nine software engineers who are all
    working 100% on OpenStack at Rackspace Australia, developed and
    deployed the turbo hipster third party CI system along with Joshua
    Hesketh, as well as writing nova code. I recognize that if I am
    successful I will need to rearrange my work responsibilities, and my
    management is supportive of that.
    
    The future
    --------------
    
    To be honest, I've thought for a while that the PTL role in OpenStack
    is poorly named. Specifically, its the T that bothers me. Sure, we
    need strong technical direction for our programs, but putting it in
    the title raises technical direction above the other aspects of the
    job. Compute at the moment is in an interesting position -- we're
    actually pretty good on technical direction and we're doing
    interesting things. What we're not doing well on is the social aspects
    of the PTL role.
    
    When I first started hacking on nova I came from an operations
    background where I hadn't written open source code in quite a while. I
    feel like I'm reasonably smart, but nova was certainly the largest
    python project I'd ever seen. I submitted my first patch, and it was
    rejected -- as it should have been. However, Vishy then took the time
    to sit down with me and chat about what needed to change, and how to
    improve the patch. That's really why I'm still involved with
    OpenStack, Vishy took an interest and was always happy to chat. I'm
    told by others that they have had similar experiences.
    
    I think that's what compute is lacking at the moment. For the last few
    cycles we're focused on the technical, and now the social aspects are
    our biggest problem. I think this is a pendulum, and perhaps in a
    release or two we'll swing back to needing to re-emphasise on
    technical aspects, but for now we're doing poorly on social things.
    Some examples:
    
    - we're not keeping up with code reviews because we're reviewing the
    wrong things. We have a high volume of patches which are unlikely to
    ever land, but we just reject them. So far in the Icehouse cycle we've
    seen 2,334 patchsets proposed, of which we approved 1,233. Along the
    way, we needed to review 11,747 revisions. We don't spend enough time
    working with the proposers to improve the quality of their code so
    that it will land. Specifically, whilst review comments in gerrit are
    helpful, we need to identify up and coming contributors and help them
    build a relationship with a mentor outside gerrit. We can reduce the
    number of reviews we need to do by improving the quality of initial
    proposals.
    
    - we're not keeping up with bug triage, or worse actually closing
    bugs. I think part of this is that people want to land their features,
    but part of it is also that closing bugs is super frustrating at the
    moment. It can take hours (or days) to replicate and then diagnose a
    bug. You propose a fix, and then it takes weeks to get reviewed. I'd
    like to see us tweak the code review process to prioritise bug fixes
    over new features for the Juno cycle. We should still land features,
    but we should obsessively track review latency for bug fixes. Compute
    fails if we're not producing reliable production grade code.
    
    - I'd like to see us focus more on consensus building. We're a team
    after all, and when we argue about solely the technical aspects of a
    problem we ignore the fact that we're teaching the people involved a
    behaviour that will continue on. Ultimately if we're not a welcoming
    project that people want to code on, we'll run out of developers. I
    personally want to be working on compute in five years, and I want the
    compute of the future to be a vibrant, friendly, supportive place. We
    get there by modelling the behaviour we want to see in the future.
    
    So, some specific actions I think we should take:
    
    - when we reject a review from a relatively new contributor, we should
    try and pair them up with a more experienced developer to get some
    coaching. That experienced dev should take point on code reviews for
    the new person so that they receive low-latency feedback as they
    learn. Once the experienced dev is ok with a review, nova-core can
    pile on to actually get the code approved. This will reduce the
    workload for nova-core (we're only reviewing things which are of a
    known good standard), while improving the experience for new
    contributors.
    
    - we should obsessively track review performance for bug fixes, and
    prioritise them where possible. Let's not ignore features, but let's
    agree that each core should spend at least 50% of their review time
    reviewing bug fixes.
    
    - we should work on consensus building, and tracking the progress of
    large blueprints. We should not wait until the end of the cycle to
    re-assess the v3 API and discover we have concerns. We should be
    talking about progress in the weekly meetings and making sure we're
    all on the same page. Let's reduce the level of surprise. This also
    flows into being clearer about the types of patches we don't want to
    see proposed -- for example, if we think that patches that only change
    whitespace are a bad idea, then let's document that somewhere so
    people know before they put a lot of effort in.
    
    Thanks for taking the time to read this email!
    


    Tags for this post: openstack juno ptl nova election
    Related posts: Thoughts from the PTL; Expectations of core reviewers; Review priorities as we approach juno-3; Havana Nova PTL elections; Juno nova mid-cycle meetup summary: nova-network to Neutron migration; Chronological list of Juno Nova mid-cycle meetup posts

posted at: 00:01 | path: /openstack/juno | permanent link to this entry


Wed, 26 Mar 2014



The Hot Gate

posted at: 02:04 | path: /book/John_Ringo | permanent link to this entry


Previous page