Open Stack

Carl Baldwin wrote:
> Armando's point #2 is a good one.  I see that we should have raised
> awareness of this more than we did.  The bulk of the discussion and
> the development work moved over to the oslo team and I focused energy
> on other things.  What I didn't realize was that the importance of
> this work to Neutron did not transfer along with it and that simply
> delivering the new functionality in oslo by Juno was not sufficient as
> Neutron would need time to incorporate it.
> 
> I am at a point now where I have some time to work on this.  If
> reconsideration for Juno is still an option at this time then I think
> what we need to do is to resolve the concerns that are still
> outstanding.  I'll admit that I really don't understand what the
> concerns are.  I believe that the security concerns have been
> addressed.  If you still have concerns around the design of this
> feature please bring them up specifically.

At this point I think it's just timing issues. There are 85 Neutron
blueprints targeted to juno-3, which is a considerable amount,
especially when compared to the 10 merged in juno-2 and the 8 merged in
juno-1). Most of that work is already proposed for review, ready to test
and merge and still won't make it purely due to reviewers bandwidth.
Establishing a review queue and excluding noise (reviews that have less
chance of making it) from it is critical to optimize the quantity of
features we'll end up merging.

The daemon work hasn't merged in oslo.rootwrap yet, the last details are
still being ironed out. I take my share of responsibility for some of
the delays in reviews there, but the fact is we had to take the time to
do it right. The neutron-side code has been ready for some time, but
until oslo.rootwrap includes the feature, you can't really review/test
that -- which means the daemon stuff is not anywhere near the top of the
review pile: it's not even in the pile at this point. I'm not totally
convinced it should jump the queue just because that code was written a
long time ago.

So we can certainly /try/ to include it in Juno, if it's seen as a
critical performance-enhancing feature: hope that we can get it in
oslo.rootwrap very soon and then propose the neutron code for review and
have fast turnaround on it. But I wouldn't bet my money on it -- I think
it might make sense to focus on reviewing stuff that is more likely to
make it (stuff that is already proposed for review) and have general
adoption of a Juno-released rootwrap daemon mode throughout all projects
during Kilo.

-- 
Thierry Carrez (ttx)