[PKG-Openstack-devel] python-keystonemiddleware dependency in Swift & patch for O_TMPFILE

[Ondrej Novy]

Hi,

2018-03-13 12:22 GMT+01:00 Thomas Goirand <zigo at debian.org>:
>
> Yesterday evening, it seems you were not happy about my last upload of
> Swift. Maybe we should try to trust each other. That's what makes good
> team. I do trust your work, and I was hoping you'd do the same for me.
> Also, if you dislike a change, then we can always discuss it together.
>

I don't trust you and I hate you, because this change is wrong. I told you
this and you still uploaded wrong fix.

When reading Swift docs, specifically this file, in the upstream source:
> doc/source/install/controller-install-debian.rst

One can read that python-keystonemiddleware needs to be installed.
>

as I already explained to you over IRC, keystonemiddleware is needed only
if you are using Keystone. For example we are not using Keystone in one of
our production Swift deployment. So after this change i need to have whole
Keystone dependency chain installed. No thanks.


> Moreover, running Tempest after the setup with the integration script
> showed that swift-proxy was stack-dumping, with problems importing
> keystonemiddleware.
>

Tempest uses config with keystone middleware specified. So we should add
this deps to package which sets this config. Default config doesn't have
this.


> While it's possible to not install keystonemiddleware if you're not
> using Keystone, it has always been the policy in the OpenStack team to
> add depends on all possible drivers, to simplify deployments. Moreover,
> using Keystone as an auth for Swift is quite a common use case.
>

sounds like Recommends/Suggest. According to Debian policy, which is more
than "OpenStack Team policy".

Using Keystone as auth for Swift is not so common. Ask IBM for example,
biggest swauth deployer.

So I wonder why you're trying to revert my change. Could you explain? If
> you don't want it to be as a hard depends, maybe at least it should be
> as a recommends for swift-proxy? (I would very much prefer a depends:)
>

first of all:

   - you asked
   - I told you: I will look into it
   - i told you: looks wrong to me
   - then I explained: It's wrong, because...
   - you uploaded

YOU should explain and talk better. But that is what I already told you,
again and again and again. You are just "doing" and you are doing it wrong.

Because it looks like it's useless to be on IRC, because you are not
communicating and uploading even after i told you "no", I consider it's
better to not talk at all and don't be there. So I left IRC. It's so boring
to explaining it again and again.

The other thing is that the unit test errors which I showed you are
> real, and due to the fact that my /tmp is mounted using tmpfs. Indeed,
> tmpfs doesn't support the O_TMPFILE option when opening files, which
> leads to that problems. So this isn't a problem in *my* build enviroment
> only. Therefore, I proposed this patch upstream:
>
> https://review.openstack.org/#/c/552093/
>
> The thing is, even if unit tests are passing, the current patch in the
> latest upload of Swift needs to be updated to that last version. Since
> you seem to not like my uploads, could you do that?
>

I don't have problem with your fix and thanks for it. (If upstream will
accept it). Because buildd and me are not using tmpfs for /tmp, my
motivation for this is low.

tl;dr: I'm preparing correct fix. Which was true from yesterday/beginning.

-- 
Best regards
 Ondřej Nový

Email: novy at ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20180313/c3b6b857/attachment.html>