Open Stack

Thanks for all the updates Jeremy :-)

On Mon, Jun 6, 2016 at 9:21 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> <snip>
>
> Store Build Logs in Swift
> -------------------------
>
>
> http://specs.openstack.org/openstack-infra/infra-specs/specs/logs-in-swift.html
>
> This seems to have taken a break, with our log volume diminishing
> significantly in the past year or so and an alternative AFS-based
> solution proposed:
>
> https://review.openstack.org/269928
>
> We should remove the original spec from our priority list (since
> that's basically already ceased to be an actual priority), and
> probably supercede it with the AFS proposal.
>
>
> <snip>



So I think we need to treat voting on 269928 as a decision to no longer
pursue storing logs in swift or not. In doing so we should consider the
pros and cons of an AFS-based storage vs swift vs lvm (aka what we're doing
now).

For context, here is an update to the swift logs spec that details what is
(known to be) left: https://review.openstack.org/#/c/254718/

To me it feels like AFS is incomplete in terms of solving the original
problems that we set out to solve with swift (such as scaling, redundancy,
durability and low administration overhead). It solves them to an extent
and perhaps that extent is acceptable (more limited damage in an outage or
failure etc).

Swift on the other hand is close but each time we get closer we run into
more problems as we discover it turns out we like posix style filesystems.

I'm not sure which solution is the right answer. It feels a bit like the
storyboard vs manifest discussions we've had where we've tried a few things
and they haven't worked perfectly so now we're all too afraid to get our
fingers burned again.

I don't have particularly strong feelings either way but in order to move
this forward we need to make a concise decision on which way we want to go.

Additionally the urgency of this spec seems to have been reduced (due to
limiting the retention on logs). We should perhaps reconsider if it's a
priority spec or not after we've decided on a path forward.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20160608/5f3b9e8d/attachment.html>