Re: [openstack-dev] [keystone] Stepping down as PTL
Thanks Dolph! On Mon, Sep 22, 2014 at 10:47 AM, Dolph Mathews dolph.math...@gmail.com wrote: Dearest stackers and [key]stoners, With the PTL candidacies officially open for Kilo, I'm going to take the opportunity to announce that I won't be running again for the position. I thoroughly enjoyed my time as PTL during Havana, Icehouse and Juno. There was a perceived increase in stability [citation needed], which was one of my foremost goals. We primarily achieved that by improving the communication between developers which allowed developers to share their intent early and often (by way of API designs and specs). As a result, we had a lot more collaboration and a great working knowledge in the community when it came time for bug fixes. I also think we raised the bar for user experience, especially by way of reasonable defaults, strong documentation, and effective error messages. I'm consistently told that we have the best out-of-the-box experience of any OpenStack service. Well done! I'll still be involved in OpenStack, and I'm super confident in our incredibly strong core team of reviewers on Keystone. I thoroughly enjoy helping other developers be as productive as possible, and intend to continue doing exactly that. Keep hacking responsibly, -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers
Daniel, Thanks for the well thought out and thorough proposal to help Nova. As an OpenStack operator/developer since Cactus time, it has definitely gotten harder and harder to get fixes in Nova for small bugs that we find running at scale with production systems. This forces us to maintain more and more custom patches in-house (or for longer periods of time). The huge amount of time necessary to shepherd patches through review discourages additional devs from contributing patches because of the amount of time investment required. I believe whatever we can do to improve the ability to fix technical debt within Nova and both keep and grow the non-core contributors of Nova would be greatly beneficial. Thanks! Nate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] bug/129135
Also, how does this work for RHEL-based distros where they tend to backport new kernel features? For instance vxlan support was added in the kernel for RHEL6.5 which is 2.6.32-based... That changeset looks like it breaks Neutron for ovs + vxlan on RHEL distros. Nate On Mon, Mar 31, 2014 at 1:07 PM, sowmini.varad...@hp.com wrote: openstack-dev, A question about the fix from https://review.openstack.org/#/c/82931 After this fix, the neutron code now explicitly checks for kernel version 3.13- was this deliberate? (I was using an older 3.11 version before, and did not seem to have any issues before this change). Is there a specific kernel patch that ovs-vxlan is dependant on? Thanks Sowmini ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] RFC - using Gerrit for Nova Blueprint review approval
On Mar 6, 2014 1:11 PM, Sean Dague s...@dague.net wrote: One of the issues that the Nova team has definitely hit is Blueprint overload. At some point there were over 150 blueprints. Many of them were a single sentence. The results of this have been that design review today is typically not happening on Blueprint approval, but is instead happening once the code shows up in the code review. So -1s and -2s on code review are a mix of design and code review. A big part of which is that design was never in any way sufficiently reviewed before the code started. In today's Nova meeting a new thought occurred. We already have Gerrit which is good for reviewing things. It gives you detailed commenting abilities, voting, and history. Instead of attempting (and usually failing) on doing blueprint review in launchpad (or launchpad + an etherpad, or launchpad + a wiki page) we could do something like follows: 1. create bad blueprint 2. create gerrit review with detailed proposal on the blueprint 3. iterate in gerrit working towards blueprint approval 4. once approved copy back the approved text into the blueprint (which should now be sufficiently detailed) Basically blueprints would get design review, and we'd be pretty sure we liked the approach before the blueprint is approved. This would hopefully reduce the late design review in the code reviews that's happening a lot now. There are plenty of niggly details that would be need to be worked out * what's the basic text / template format of the design to be reviewed (probably want a base template for folks to just keep things consistent). * is this happening in the nova tree (somewhere in docs/ - NEP (Nova Enhancement Proposals), or is it happening in a separate gerrit tree. * are there timelines for blueprint approval in a cycle? after which point, we don't review any new items. Anyway, plenty of details to be sorted. However we should figure out if the big idea has support before we sort out the details on this one. Launchpad blueprints will still be used for tracking once things are approved, but this will give us a standard way to iterate on that content and get to agreement on approach. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm very much in favor of this idea. One of the topics we discussed at the OpenStack Operator day this week was just this problem. The lack of alerts/notification of new blueprint creation and the lack of insight into design architecture, feedback, and approval of them. There are many cases where Operators would like to provide feedback to the design process of new features early on to ensure upgrade compatibility, scale, security, HA, and other issues of concern to Operators. This would be a great way to get them more involved in the process. Nate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
