Hi, I have some plans in Mitaka cycle.
1. AZ support[1] - I proposed AZ support in Liberty but the millstone is Mitaka now. The spec has been merged in Mitaka. I keep to propose the patches on Gerrit. 2. LinuxbrideDVR - I'm trying to create concrete implementation and then I achieve it nearly. I will propose BP or RFE bug ASAP. 3. Router status update[2] - I proposed it as bug[3] but some folks disagreed with this. I will classify the requirements and propose the implementation. 4. Devstack - In Liberty cycle, I was aimed at removing plugin restriction from devstack so that vendor plugin maintainers easily keep to maintain the code in their tree. And also I tried to improve the quality for neutron. I’ve already finished some works. I will keep to contribute to devstack for neutron in Mitaka cycle including discussion about neutron repo vs devstack repo. If you have trouble with devstack related to neutron(especially devstack plugin), I can help you. 5. More - I keep to contribute something else(especially logic for operators) for neutron :) [1]: https://blueprints.launchpad.net/neutron/+spec/add-availability-zone <https://blueprints.launchpad.net/neutron/+spec/add-availability-zone> [2]: https://blueprints.launchpad.net/neutron/+spec/l3-router-status <https://blueprints.launchpad.net/neutron/+spec/l3-router-status> [3]: https://bugs.launchpad.net/neutron/+bug/1341290 <https://bugs.launchpad.net/neutron/+bug/1341290> Thanks, Hirofumi > On 2015/10/01, at 23:02, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > >> On 01 Oct 2015, at 15:45, Ihar Hrachyshka <ihrac...@redhat.com> wrote: >> >> Hi all, >> >> I talked recently with several contributors about what each of us plans for >> the next cycle, and found it’s quite useful to share thoughts with others, >> because you have immediate yay/nay feedback, and maybe find companions for >> next adventures, and what not. So I’ve decided to ask everyone what you see >> the team and you personally doing the next cycle, for fun or profit. >> >> That’s like a PTL nomination letter, but open to everyone! :) No >> commitments, no deadlines, just list random ideas you have in mind or in >> your todo lists, and we’ll all appreciate the huge pile of awesomeness no >> one will ever have time to implement even if scheduled for Xixao release. >> >> To start the fun, I will share my silly ideas in the next email. > > Here is my silly list of stuff to do. > > - start adopting NeutronDbObject for core resources (ports, networks) [till > now, it’s used in QoS only]; > > - introduce a so called ‘core resource extender manager’ that would be able > to replace ml2 extension mechanism and become a plugin agnostic way of > extending core resources by additional plugins (think of port security or qos > available for ml2 only - that sucks!); > > - more changes with less infra tinkering! neutron devs should not need to go > to infra projects so often to make an impact; > -- make our little neat devstack plugin used for qos and sr-iov only a huge > pile of bash code that is currently stored in devstack and is proudly called > neutron-legacy now; and make the latter obsolete and eventually removed from > devstack; > -- make tempest jobs use a gate hook as we already do for api jobs; > > - qos: > -- once we have gate hook triggered, finally introduce qos into tempest runs > to allow first qos scenarios merged; > -- remove RPC upgrade tech debt that we left in L (that should open path for > new QoS rules that are currently blocked by it); > -- look into races in rpc.callbacks notification pattern (Kevin mentioned he > had ideas in mind around that); > > - oslo: > -- kill the incubator: we have a single module consumed from there (cache); > Mitaka is the time for the witch to die in pain; > -- adopt oslo.reports: that is something I failed to do in Liberty so that I > would have a great chance to do the same in Mitaka; basically, allow neutron > services to dump ‘useful info’ on SIGUSR2 sent; hopefully will make debugging > a bit easier; > > - upgrades: > -- we should return to partial job for neutron; it’s not ok our upgrade > strategy works by pure luck; > -- overall, I feel that it’s needed to provide more details about how > upgrades are expected to work in OpenStack (the order of service upgrades; > constraints; managing RPC versions and deprecations; etc.) Probably devref > should be a good start. I talked to some nova folks involved in upgrades > there, and we may join the armies on that since general upgrade strategy > should be similar throughout the meta-project. > > - stable: > -- with a stadium of the size we have, it becomes a burden for > neutron-stable-maint to track backports for all projects; we should think of > opening doors for more per-sub-project stable cores for those subprojects > that seem sane in terms of development practices and stable awareness side; > that way we offload neutron-stable-maint folks for stuff with greater impact > (aka stuff they actually know). > > And what are you folks thinking of? > > Ihar > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
