Re: Package naming rant
Hi Enrico,
Thanks for, via IRC, pointing me to your post, and for your message itself.
On 04/17/2016 03:43 PM, Enrico Zini wrote:
> Then, OpenStack packages. Which of these are actual openstack things?
>
> Oslo, Tataouine, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
> Schinkenzwiebelmettwurst, Ceilometer, Fuel, Shade, Antani, Congress,
> Barbican, Taskflow, Tosca, Shaft, Trove, Brazier, Mellanox, Manila,
> Tripleo, Castellan, Murano, Hoverboard, Ironic, Swift, Tuskar,
> Capacitor, Ember, Perth, Nova, Inculo, Arista, Neutron, Rally,
> Designate, Cinder, Shotgun, Kulfi, Kofte, Senlin, Braciola, Mocha,
> Lido, Horizon, Zaqar, Heat, Calippo.
I'm not sure where you got that list, but a number of these packages
aren't from OpenStack. Or at least, I never heard of such projects, and
they aren't packaged. On your list, here's what I've uploaded on Sid:
> Oslo, Magnum, Rump, Keystone, Mistral, Glance, Sahara,
> Ceilometer, Fuel, Shade, Antani, Congress,
> Barbican, Taskflow, Trove, Mellanox, Manila,
> Tripleo, Castellan, Murano, Ironic, Swift,
> Nova, Arista, Neutron, Rally,
> Designate, Cinder, Shotgun, Senlin,
> Horizon, Zaqar, Heat
Now, about the naming itself, let me give my opinion.
I could have pre-fixed all packages with "openstack-" like they did in
RDO/Red Hat, but this has proven to be really not convenient at all for
OpenStack users, with for example, names like this one:
neutron-openvswitch-agent
Add OpenStack and it becomes:
openstack-neutron-openvswitch-agent
This IMO is a way too long.
The OpenStack PKG group on Alioth contains currently 371 source
packages, out of which a bit more than 100 are general purpose Python
libs (so it'd be fair to say we have more than 200 source packages).
Adding an "openstack-" prefix would be really a lot of additional
typing, both for package maintainers and final users, and it wouldn't
help our final users so much.
More over, I don't believe the OpenStack packages are in any way
"polluting the namespace", as these names are carefully crafted so that
what is chosen doesn't exist anywhere else. It's been proven to be wrong
a few times though, but that's mostly the case.
> That wins the second place in my personal "let's spam the package
> namespace with meaningless names" rank.
None of the names are meaningless. I could provide explanations for each
and every one of them (though probably nobody in this list cares about it).
> Let's take this package:
>
> python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
> Create and save Fuel diagnostic snapshots
>
> I thought it was about shooting yourself in the foot, by connecting an
> untested tool you just saw on Hacker News to the OBD-II port of your
> car.
>
> Nope: it's some openstack thing with a description made of 11 lines of
> enterprise nonsense and two lines of "it reads yaml, collects log files
> and stuff, and helps diagnose stuff".
One of the things shotgun does is actually destroying a node who failed
to deployed, so that it reboots and can be re-provisioned, which
explains the name. Over time, its main mission changed to what it is
right now: a diagnostic utility who collects deployment logs. Shotgun is
part of Fuel, and it makes no sense to describe Shotgun without
explaining what Fuel is, as it is pretty much useless without Fuel.
I'm sorry if you feel like the description of Fuel is looking like
"enterprise nonsense". I don't really like it so much either, and
probably I should rewrite what's from upstream. Please feel free to
provide something better, and I'll propagate it to all Fuel packages.
Also, for many packages, upstream is providing either a very small, or
even an non-existent description of the package. That's also the case
for shotgun: have a look at the README.rst from upstream:
https://github.com/openstack/shotgun
I'm often taking a lot of time to make sure that the short and long
descriptions are good enough for Debian. Sometimes, I even have to
investigate to understand what the packages does, as it comes just as a
mandatory dependency, and upstream didn't care at all to write a
description. Of course, I always accept contributions, and mostly,
upstream too.
> Please at least make sure that all the openstack packages have
> suite::openstack tags assigned, and then let's figure out how to have
> apt run some recipes to make some tags available in the package short
> descriptions, so that it can show like this on "apt search":
>
> python-shotgun/testing,testing 0.1.0+2016.12.30.git.0682f20c42-1 all
> [openstack] Create and save Fuel diagnostic snapshots
I once took the time to manually edit tags of all OpenStack packages.
However, I gave up, because it took too long to use the web interface,
which didn't propose to do multi-edit (ie: add a group of tags to
multiple packages at once). After I asked you, you then explained to me
how I could script it, but that was too complicated, and then I finally
gave up.
Moving forward, what I would like to see is an easy to use shell tool to
do what's needed. For example, something like this:
debtags -kAC6B43FE -p python-shotgun \
-t implemented-in::python,role::program,suite::openstack,system::cloud
I don't think it'd be hard to implement, especially as you're a Python
guru yourself, and there's already an API. Maybe the only part that
would be a trouble would be the authentication (on the above I used a
PGP key, but maybe it'd be possible to re-use client certs?). Or maybe
such a client already exists and I missed it?
If I had such a tool available, I'd be tagging all of my packages very
shortly. Without it, I feel like I have to write the tool first,
otherwise, it will take too long.
Also, I was very disappointed to realize lots of the tags I edited a few
years ago for OpenStack seem to be completely gone (or at least, they
don't show on the web editor). What happened?
Hoping the above is giving you some insights, and will help improving
debtags too.
Cheers,
Thomas Goirand (zigo)
Reply to: