Open Stack

Folks,

First, let me report current feature status: we continued the work with
Bogdan Dobrelya and Sergii Golovatiuk. I have incorporated their feedback
into the change. Also, I have fully tested it on custom ISO and Fuel CI
passes successfully. Also, I have an approval from Bogdan on the
implementation of the change (see his +2 before he casted -2 because of FF).

Now, I still would like to ask the change to be merged into 8.0 due to the
following reasons:
1. It is small and isolated
2. It is disabled by default and marked as experimental
3. It promises big value by reducing load on RabbitMQ, which becomes
bottleneck on big environments

Thanks,

Dmitry

The CR: https://review.openstack.org/#/c/249180

2015-12-08 13:11 GMT+03:00 Igor Kalnitsky <ikalnitsky at mirantis.com>:

> Hey Dmitry,
>
> Despite the fact the feature promises performance boost (IIUC) and
> it's really nice to have it, I agree with Mike's opinion - it's late
> to continue working on features. Each delay means less time to test
> it, and we need to focus on quality.
>
> I'm sorry, but I have to say "No" on requested exception.
>
> - Igor
>
> On Tue, Dec 8, 2015 at 9:55 AM, Mike Scherbakov
> <mscherbakov at mirantis.com> wrote:
> > Hi Dmitry,
> > as much as I support the change, and glad that we got time for it, my
> > opinion is that we should not extend a FFE. I have following reasons to
> > think this way:
> >
> > 1) Feature Freeze is time based milestone, with the rational "FF ensures
> > that sufficient share of the ReleaseCycle is dedicated to QA, until we
> > produce the first release candidates. Limiting the changes that affect
> the
> > behavior of the software allow for consistent testing and efficient
> > bugfixing" [1]. Even though this feature will be disabled by default, it
> is
> > important to note the first part of this rationale - we need to focus on
> > stability now, not on features.
> > 2) 7 FFEs for Fuel [2] I'd subjectively consider as high number, as in
> total
> > there are ~25 major blueprints to be delivered. Dmitry, our PTL,
> > unfortunately is absent for a couple of weeks, but his opinion is quite
> > similar: "The list of exceptions is much longer than I'd like, and some
> have
> > larger impact than I'd like, lets all of us make sure we don't come to
> > regret granting these exceptions." [3]. Taking any exception further
> means
> > moving FF, in fact. That means moving of release date, which I don't
> think
> > we should even consider doing.
> > 3) Exception to exception, in my opinion, should only be allowed in
> > extremely rare cases for essential features only. When it becomes clear
> that
> > the whole release has a major gap or serious issue, which can only be
> > resolved by finishing an essential feature. I have no evidence to think
> that
> > this functionality, which will be disabled by default, can fall into this
> > category.
> > 4) Changeset [4] has a change to the packaging spec. Any small change to
> > packaging after FF imposes additional risk, as there is no good test
> > automation for such kind of changes. Even if it's just include of a new
> > file. In case of regression, we may easily lose a day for figuring out
> what
> > is wrong and reverting a change.
> >
> > I'd like to hear component leads while PTL is absent these days....
> >
> > [1] https://wiki.openstack.org/wiki/FeatureFreeze
> > [2]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html
> > [3]
> >
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081149.html
> > [4] https://review.openstack.org/#/c/249180/
> >
> > On Mon, Dec 7, 2015 at 2:30 PM Adam Heczko <aheczko at mirantis.com> wrote:
> >>
> >> Hello Dmitry,
> >> I like this idea and very much appreciate it.
> >> +1 from me :)
> >>
> >> A.
> >>
> >> On Mon, Dec 7, 2015 at 9:48 PM, Dmitry Mescheryakov
> >> <dmescheryakov at mirantis.com> wrote:
> >>>
> >>> Hello folks,
> >>>
> >>> I'd like to request extension of current FFE for the feature [1].
> During
> >>> the three FFE days we merged the spec [2] after big discussion and
> made a
> >>> couple iterations over the implementation [3]. We had a chat with
> Bogdan on
> >>> how to progress and here are the action items still need to be done:
> >>>  * part of the change responsible for RabbitMQ policy need to be
> >>> upstreamed first to RabbitMQ repo.
> >>>  * the change needs to be review and merged by our library folks.
> >>>
> >>> Overall I think that 2-3 more days should be enough to finish it.
> >>>
> >>> What do you think folks?
> >>>
> >>> Dmitry
> >>>
> >>> [1]
> >>>
> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc
> >>> [2] https://review.openstack.org/247517
> >>> [3] https://review.openstack.org/249180
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> 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
> >>>
> >>
> >>
> >>
> >> --
> >> Adam Heczko
> >> Security Engineer @ Mirantis Inc.
> >>
> __________________________________________________________________________
> >> 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
> >
> > --
> > Mike Scherbakov
> > #mihgen
> >
> >
> __________________________________________________________________________
> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151211/ca5ad31e/attachment.html>