Open Stack

Hi Luigi,

First thanks for communicating about this.

I'm afraid you probably will not like much what I'm going to have to
write here. Sorry in advance if I'm not enthusiastic about this.

On 12/11/18 9:54 PM, Luigi Toscano wrote:
> == Packaging
> 
> It would be nice if users could get all the plugins packages by installing the 
> same packages as before the split, but I understand that it may be tricky, 
> because each plugin depends on the core of sahara. This means that a binary 
> subpackage like openstack-sahara (RDO) or sahara (Debian) can't depend on the 
> binary packages of the plugins, or that would introduce a circular dependency.
> 
> I raised the issue on the RDO list to get some initial feedback and the 
> solution that we are going to implement in RDO requires flipping the value of 
> a variable to handle the bootstrap case and the normal case, please check:
> https://lists.rdoproject.org/pipermail/dev/2018-November/008972.html
> and the rest of the thread, like:
>  https://lists.rdoproject.org/pipermail/dev/2018-December/008977.html
>  
> Any additional idea from other packagers would be really appreciated, also 
> because it has a direct impact on at least the puppet modules.

We aren't "packagers", we *maintain* packages, and therefore are package
maintainers. And from that perspective, such decision from upstream is
always disruptive, both from the package maintainer view, and for our users.

While a plugin architecture looks sexy from the outside, it can bite
hard in many ways.

In argumentation in the spec, the one and only thing which is annoying
your users (according to the argumentation) is that plugins are tight to
a milestone, and that it's not possible to upgrade a plug-in separately.
I seriously doubt that Sahara users are going to do that, for many
reasons. Here's 2 of them.

First, because if they consume packages, I don't see downstream
distribution making update to packages so often. Especially if there's
so many to update, and so many combination to test, it's going to be
very difficult for downstream distribution to know what to do, and do
regular plugin updates.

Second, because I very much doubt that users will want to update their
plugins that often. Most OpenStack users are struggling with updates of
the OpenStack core already.

Another thing is experience we had with Cinder and Neutron. As you know,
Cinder carries the drivers in the main repository, while Neutron decided
to move to a plugin system. So we do trust the Cinder team to do a good
job to maintain the plugins, and have them in sync with the release, for
some Neutron plugins, it has been a complete disaster, with some plugins
always lagging behind the needed API changes and so on. As for
downstream distribution, it is very hard to know which plugins are worth
packaging or not, and even harder to know which are well maintained
upstream or not. What's your plan for addressing this issue?

As for myself, I'm really not sure I'm going to invest so much time on
Sahara packaging plugin. Maybe I'll decide to package a few, but
probably not all plugins, as it's very time consuming. Maybe I'll find
spare cycles. It wont be important anyway, because Debian Buster will be
frozen, so I may just skip that work for the Stein release, as I'll
probably be busy on other stuff. So, not best timing for me as a Debian
package maintainer. :/

So, maybe you could reconsider? Or is it already too late?

> == Preview
> 
> The work-in-progress repositories are available here:
> 
> Sahara: https://github.com/tellesnobrega/sahara/tree/split-plugins
> 
> Plugins:
> * Ambari: https://github.com/tellesnobrega/sahara-plugin-ambari
> * CDH: https://github.com/tellesnobrega/sahara-plugin-cdh
> * MapR: https://github.com/tellesnobrega/sahara-plugin-mapr
> * Spark: https://github.com/tellesnobrega/sahara-plugin-spark
> * Storm: https://github.com/tellesnobrega/sahara-plugin-storm
> * Vanilla: https://github.com/tellesnobrega/sahara-plugin-vanilla

Oh gosh... This becomes very embarrassing. I have absolutely no clue
what these plugins are for, and there's absolutely no clue in the
repositories. Appart from "Spark", which I vaguely heard about, the
above names give zero clue on what they do. There's no hyperlink to the
projects these plugins are supporting. I have no clue which of the above
plugins is for Hadoop, which was historically the first target of Sahara.

Please, please please please, for each plugin, provide:
- A sort description of 80 chars, in one line
- A long description of *AT LEAST* 3 lines of 80 chars

That's IMO the minimum you own to the downstream package maintainers
that are doing the work for your project for free (that's really my
case, I never used Sahara, and I have zero professional insentive to
package it, I really do it as a courtesy for Debian and OpenStack users).

Thanks for working on Sahara,
Cheers,

Thomas Goirand (zigo)

P.S: I've disregarded the added amount of work that all of this change
imposes to all of us, as I thought you knew already about it, but this
is not a good news to know 6 new packages will be needed... :(