[PKG-Openstack-devel] rabbit_* deprecated

[Thomas Goirand]

On 10/17/2016 11:49 PM, Turbo Fredriksson wrote:
> But there's nothing stopping you to either modifying the config file
> upstream provides, OR (even better - that lets you actually deprecate
> stuff more freely) is to provide your own template config file.

The "template config file" that you're talking about is basically done
by writing a python module. Let me explain a little bit.

Take python-keystonemiddleware (the source package), and open setup.cfg.
In there, under [entry_points], there is:

oslo.config.opts =
    keystonemiddleware.auth_token = foo.bar:list_opts

"keystonemiddleware.auth_token" is the oslo.config namespace, as used by
oslo-config-generator. It in fact uses the function list_opts within
keystonemiddleware/foo/bar.py.

So basically, instead of keystonemiddleware.auth_token, I could write my
own python module to generate a list of options, so that when invoking
oslo-config-generator, I'd use that custom namespace to replace the bad
one from keystonemiddleware.

> It adds another manual step every time a major release is released,
> BUT that's "your job" [as a package developer/maintainer!! :)].

I already manually write the namespace list in debian/rules for every
release, so that wouldn't be more work to just use the custom
oslo-config-generator namespace.

> I think I remember filing at least one issue that was because the
> config file didn't come with proper templates, but I think you
> closed that because upstream didn't provide proper config files.

Hum... If I remember correctly, the issue was that upstream wasn't using
oslo-config-generator at all, which is hardly fixable in the long term
without directly fixing upstream code. And that's simply too much work
for me, on top of all the packaging.

> Looking at my own host setup scripting, I have at least six config
> files locally that I download onto the host when it's setup.

Do you mean 6 custom config files to replace the ones form the package?
Could you list them, so that I can see what you think should be fixed?

> I'm using PXE booting to setup my control/compute nodes, and it
> starting to be a little TO complex :(. But that's the only way
> I can think of that lets me have 100% control over what's happening
> AND keep a track of each change (the whole setup is in GIT repo).

Most OpenStack installers are using PXE to install an operating system,
then they customize the config files with scripts. What you're doing
isn't very much different.

> But having all the options for setup with pkgos_inifile() is absolutly
> vital for me! Just setting up a Compute node, I make 132 calls to
> that! And 406 for a Control node.

It'd be nice if you could share this. Even better if you could
contribute to openstack-meta-packages so that it would be able to setup
multi-node. I am convinced that what I've been doing there is the right
approach and that it wouldn't need too much work to make it possible to
setup a "remote compute node", just by moving the osinstallrc file it
produces.

Cheers,

Thomas Goirand (zigo)