Open Stack

On 12/10/21 5:29 PM, Jean-Philippe Evrard wrote:
> Totally agree. I have so many points I want to raise. I realise asking what I have in mind will cause more trouble on this mailing list than the value it will bring. I just want the TC to think broader than the "we used to do it this way, and this is the only way".

Willing to change things within OpenStack is a completely different
topic than "doing things my own way". I very welcome change if you have
a cross-project attitude but I don't welcome "we don't do like the
others, because we can" type of thinking.

Packaging Telemetry, I've hated many times the design decision that was
just a little bit different. It wasn't better or worse, just different.
And it caused a lot of troubles just because I had to learn "their way"
of doing things. I suppose the experience was the same for contributors.

For example, aodh has it's build-dependency (well, "test requirements"
if you prefer the Python wording than the distro ones) in setup.cfg
instead of test-requirements.txt. Both works, but when I upgrade any
component, I diff the test-requirements.txt between version, to see if
there's new Build-Depends: to add to my package. But with Aodh, I have
to remember to do it with setup.cfg. Its *VERY* annoying. Yes, I'm aware
that this way, Aodh can have different test-requirements for mysql and
postgresql for example. But this is still very annoying. I would have
very much prefer if the Telemetry guys pushed so that *ALL* projects
would move to push test-requirements.txt within setup.cfg, and *THEN* I
would have accepted the change.

Do you see where I'm going? :)
I have other examples in mind, but I believe what's above is enough.

> I am sure the topic raised some questions, and will give enough food for thoughts. Hence, I hope it will result in the improvement of OpenStack :)

If you don't do things on your own different than the others, and push
every projects to move one direction at the same time then it's going to
be an improvement. If you are the only one doing your own way, it's
going to be a regression, and a pain for everyone.

>> Just my opinion, but I think buying into container hype to the point
>> where we make OpenStack only deployable through containerization
>> would be a massive step backwards.
> 
> I didn't say it was a goal or if I consider this important.
> I just wanted to mention that they are other ways to consume software than distribution packages.

Probably, but it's not up to you to decide for the others how they want
to consume your deliverables.

> Side note: I have spent to much time on this, so I will just step out now.
> I hope the TC got enough details about what to make out of this in the future.
> If you need an extra $0.02, you know where to find me :)
> 
> Regards,
> Jean-Philippe Evrard (evrardjp)

I very much hope that Skyline will be in a super nice shape in 6 months
from now, so I can include in in Debian Bookworm! :)

By the way, we discussed Python packaging a lot, but never JS. There's a
huge discussing that sooner or later will have to get started too. NPM
is a very dangerous thing that often leads to "npm install world" (ie: a
JS orgy that is barely maintainable). I have to admit that I didn't look
closely into how that's done in Skyline. But let's just take something
else as the worst example: Grafana. I've heard someone from Red Hat
attempted to package it, and discovered it included (directly or
indirectly) 1600 JS packages, and then gave-up. How is Skyline in this
regard?

Cheers,

Thomas Goirand (zigo)