Open Stack

On 13/02/15 16:22 -0800, Chris St. Pierre wrote:
>That's good to know, but I'm still just the weensiest bit confused. The code is
>unreachable and unusable -- which is a bit more forceful than just redundant or
>deprecated. Can it be removed? Does Zhi Yan have plans to do that? Is there
>anything I can do to help?

I'd say, feel free to propose a patch to remove it. Please, file a bug
for this so we can track it.

Thanks,
Flavio

>
>Thanks!
>
>On Fri, Feb 13, 2015 at 5:19 AM, Flavio Percoco <flavio at redhat.com> wrote:
>
>    On 12/02/15 09:34 -0800, Chris St. Pierre wrote:
>
>        Yeah, that commit definitely disables the file-backed queue -- it
>        certainly
>        *looks* like we want to be rid of it, but all of the code is left in
>        place and
>        even updated to support the new format. So my confusion remains.
>        Hopefully Zhi
>        Yan can clarify.
>
>        Link added. Thanks.
>
>
>
>    Hi Chris,
>
>    I touched bases with Zhi Yan and my understanding is right. Since
>    Juno, we switched to using a queue based on database instead of file
>    and the file queue is considered redundant and on its way to be
>    deprecated.
>
>    I'll also reply on the review,
>
>    Thanks for bringing this up,
>    Flavio
>
>
>
>        On Thu, Feb 12, 2015 at 12:59 AM, Flavio Percoco <flavio at redhat.com>
>        wrote:
>
>           On 11/02/15 13:42 -0800, Chris St. Pierre wrote:
>
>               I recently proposed a change to glance to turn the file-backed
>        scrubber
>               queue
>               files into JSON: https://review.openstack.org/#/c/145223/
>
>               As I looked into it more, though, it turns out that the
>        file-backed
>               queue is no
>               longer usable; it was killed by the implementation of this
>               blueprint: https://
>               blueprints.launchpad.net/glance/+spec/image-location-status
>
>               But what's not clear is if the implementation of that blueprint
>        should
>               have
>               killed the file-backed scrubber queue, or if that was even
>        intended.
>               Two things
>               contribute to the lack of clarity:
>
>               1. The file-backed scrubber code was left in, even though it is
>               unreachable.
>
>               2. The ordering of the commits is strange. Namely, commit
>        66d24bb
>               (https://
>               review.openstack.org/#/c/67115/) killed the file-backed queue,
>        and
>               then,
>               *after* that change, 70e0a24 (https://review.openstack.org/#/c/
>        67122/)
>               updates
>               the queue file format. So it's not clear why the queue file
>        format
>               would be
>               updated if it was intended that the file-backed queue was no
>        longer
>               usable.
>
>               Can someone clarify what was intended here? If killing the
>        file-backed
>               scrubber
>               queue was deliberate, then let's finish the job and excise that
>        code.
>               If not,
>               then let's make sure that code is reachable again, and I'll
>        resurrect
>               my
>               blueprint to make the queue files suck less.
>
>               Either way I'm happy to make the changes, I'm just not sure what
>        the
>               goal of
>               these changes was, and how to properly proceed.
>
>               Thanks for any clarification anyone can offer.
>
>
>           I believe the commit you're looking for is this one:
>           f338a5c870a36e493f8c818fa783942d1e0565a4
>
>           There the scrubber queue was switched on purpose, which leads to the
>           conclusion that we're moving away from it. I've not participated in
>           discussions around the change related to the scrubber queue so I'll
>           let Zhi Yan weight in here.
>
>           Thanks for bringing this up,
>           Flavio
>
>           P.S: Would you mind putting a link to this discussion on the spec
>           review?
>
>
>
>
>
>               --
>               Chris St. Pierre
>
>
>             
>         __________________________________________________________________________
>               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
>
>
>
>           --
>           @flaper87
>           Flavio Percoco
>           
>         __________________________________________________________________________
>           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
>
>
>
>
>
>        --
>        Chris St. Pierre
>
>
>        __________________________________________________________________________
>        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
>
>
>
>    --
>    @flaper87
>    Flavio Percoco
>
>    __________________________________________________________________________
>    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
>
>
>
>
>
>--
>Chris St. Pierre

>__________________________________________________________________________
>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


-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150214/290eec92/attachment.pgp>