On 2013-12-06 16:30, Clint Byrum wrote:
Excerpts from Ben Nemec's message of 2013-12-06 13:38:16 -0800:
On 2013-12-06 15:14, Yuriy Taraday wrote:
> Hello, Sean.
>
> I get the issue with upgrade path. User doesn't want to update config unless
one is forced to do so.
> But introducing code tha
Excerpts from Ben Nemec's message of 2013-12-06 13:38:16 -0800:
>
>
> On 2013-12-06 15:14, Yuriy Taraday wrote:
>
> > Hello, Sean.
> >
> > I get the issue with upgrade path. User doesn't want to update config
> > unless one is forced to do so.
> > But introducing code that weakens security
On 2013-12-06 15:14, Yuriy Taraday wrote:
> Hello, Sean.
>
> I get the issue with upgrade path. User doesn't want to update config unless
> one is forced to do so.
> But introducing code that weakens security and let it stay is an
> unconditionally bad idea.
> It looks like we have to we
Hello, Sean.
I get the issue with upgrade path. User doesn't want to update config
unless one is forced to do so.
But introducing code that weakens security and let it stay is an
unconditionally bad idea.
It looks like we have to weigh two evils: having troubles upgrading and
lessening security. T
Excerpts from Sean Dague's message of 2013-12-06 09:47:03 -0800:
> So it still seems that we are at an impasse here on getting new olso
> lockutils into cinder because it doesn't come with a working default.
>
> As a recap - https://review.openstack.org/#/c/48935/ (that sync)
>
> is blocked by fa
So it still seems that we are at an impasse here on getting new olso
lockutils into cinder because it doesn't come with a working default.
As a recap - https://review.openstack.org/#/c/48935/ (that sync)
is blocked by failing upgrade testing, because lock_path has no default,
so it has to land co