[openstack-dev] [neutron] New cycle started. What are you up to, folks?
rsblendido at suse.com
Mon Oct 5 10:13:17 UTC 2015
Very nice thread Ihar!
Here are my plans:
1. Get the last patches of the blueprint restructure-l2-agent merged
and keep working on improving the agent. Some code refactor is
definitely needed and I'd like to add multiple workers.
2. Introducing oslo versioned objects
3. Make it easier to get started in Neutron.
- mentor people
- write docs/blog posts
- in general simplify the current code when possible
4. Getting some performance data and store them for future reference
On Mon, 2015-10-05 at 18:29 +0900, Hirofumi Ichihara wrote:
> I have some plans in Mitaka cycle.
> 1. AZ support
> - 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
> - I proposed it as bug 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 :)
> : https://blueprints.launchpad.net/neutron/+spec/add-availability-zone
> : https://blueprints.launchpad.net/neutron/+spec/l3-router-status
> : https://bugs.launchpad.net/neutron/+bug/1341290
> > On 2015/10/01, at 23:02, Ihar Hrachyshka <ihrachys at redhat.com>
> > wrote:
> > > On 01 Oct 2015, at 15:45, Ihar Hrachyshka <ihrachys at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev