Open Stack

On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman <mdorman at godaddy.com> wrote:

> Well I think we can all agree this is an irritation.  But how are others
> actually dealing with this problem?  (Maybe it’s less complicated in
> Ubuntu.)
>
> The sense I get is that most people using Anvil, or other custom-ish
> packaging tools, are also running config management which handles
> generating the config files, anyway.  So you don’t so much care about the
> contents of the config file shipped with the package.
>
> Is that accurate for most people?  Or are folks doing some other magic to
> get a good config file in the packages?
>

The docs team -- reallly, Matt Kassawara -- regularly logs bugs for
packagers to put in better, working, default config files.

We do generate documentation for all the configurations across projects
that use oslo.config (and even for swift, which doesn't). So you can rely
on this reference:
http://docs.openstack.org/juno/config-reference/content/

You can also see new, updated, and deprecated options for each service,
such as:
http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html

I don't believe our reference document was what encouraged devs to take the
sample config generation out-of-tree, but I am letting you know your best
option besides troubleshooting generating it yourself.

Anne


>
> Mike
>
>
>
>
>
> On 12/9/14, 5:02 PM, "Kris G. Lindgren" <klindgren at godaddy.com> wrote:
>
> >So more to my point on the latest version of RHEL and doing: yum install
> >tox -egenconfig
> >
> >ceilometer-2014.2.1]# tox -egenconfig
> >ERROR: tox version is 1.4.2, required is at least 1.6
> >
> >
> >nova-2014.2.1]# tox -egenconfig
> >ERROR: tox version is 1.4.2, required is at least 1.6
> >
> >
> >glance-2014.2.1]# tox -egenconfig
> >ERROR: tox version is 1.4.2, required is at least 1.6
> >
> >
> >[root at localhost ~]# pip install --update tox
> >(Updated tox to 1.8.1 , upgraded virtualenv to 1.10.1 and upgraded py to
> >1.4.14)
> >
> >glance-2014.2.1]# tox -egenconfig
> >genconfig create: /root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig
> >genconfig installdeps:
> >-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,
> >-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt
> >ERROR: invocation failed (exit code 1), logfile:
> >/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log
> >ERROR: actionid=genconfig
> ><SNIP>
> >
> >Running setup.py install for MySQL-python
> ><SNIP>
> >   /usr/include/mysql/my_config_x86_64.h:654:2: error: #error
> ><my_config.h> MUST be included first!
> >     #error <my_config.h> MUST be included first!
> >      ^
> >    error: command 'gcc' failed with exit status 1
> ><snip>
> >__________________________________________________________________ summary
> >__________________________________________________________________
> >ERROR:   genconfig: could not install deps
> >[-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt,
> >-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt]; v =
> >InvocationError('/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/bin/p
> >i
> >p install --allow-all-external --allow-insecure netaddr -U
> >-r/root/rpmbuild/BUILD/glance-2014.2.1/requirements.txt
> >-r/root/rpmbuild/BUILD/glance-2014.2.1/test-requirements.txt (see
> >/root/rpmbuild/BUILD/glance-2014.2.1/.tox/genconfig/log/genconfig-1.log)',
> >1)
> >
> >
> >
> >So a few things to point out in order to even get tox -egenconfig I had to
> >update the system packages versions using pip.  Since we have other python
> >packages using virtualenv I have no idea if the updated venvironment
> >package is going to break those systems or not.  So the included
> >script/command is already a barrier to getting a sample config.  2) tox
> >fails to even build all the deps - it happens to be exactly failing at
> >mysql in both nova/cinder/glance/keystone 3) It's installing it own
> >versions of python libraries that solve the dependencies that are then
> >going to be used to generate the configuration.  If the configuration is
> >so dynamic that getting a different version of oslo.config could generate
> >a sample configuration that wont work on my system then how am I suppose
> >to deal with:
> >Tox installed version:
> >oslo.config-1.5.0
> >
> >
> >System installed version:
> >python-oslo-config-1.3.0
> >
> >
> >
> >
> >Also python-libvrit failed to build because I don¹t have libvrit installed
> >on this system.  So am I to assume that there are no libvrit options
> >(which we both know is false)?
> >Now I can get a example config - that wont work with my system - per what
> >everyone else has been saying.  Also, at what point would the average user
> >just say "F it"? - because at the point I feel like if I was an average
> >user - I would be there right now.
> >____________________________________________
> >
> >Kris Lindgren
> >Senior Linux Systems Engineer
> >GoDaddy, LLC.
> >
> >
> >On 12/9/14, 8:14 AM, "Mathieu Gagné" <mgagne at iweb.com> wrote:
> >
> >>On 2014-12-08 11:01 PM, Kris G. Lindgren wrote:
> >>>
> >>>   I don¹t think its too much to ask for each project to include a
> >>>script
> >>> that will build a venv that includes tox and the other relevant deps to
> >>> build the sample configuration.
> >>
> >>This is already the case. Back then, I did the work of documenting how
> >>you could generate the sample config files for each projects (I cared
> >>about):
> >>http://blog.mgagne.ca/generating-sample-config-files-in-openstack/
> >>
> >>You can see that the process isn't streamlined. Each project has its own
> >>particularities. Some projects don't use the (un)official standard "tox
> >>-egenconfig" command, I patched some projects to make it less a pain.
> >>
> >>And my thoughts about sample config files:
> >>http://blog.mgagne.ca/where-are-the-sample-config-files/
> >>
> >>I wrote it after Cinder proposed removing its sample config file. They
> >>abandoned the patch at that time but now sample config file is gone.
> >>
> >>It's not an easy problem because core libraries used by OpenStack
> >>projects also use oslo.config and configs required by those libraries
> >>are part of the main configurations required for a project to even work.
> >>([database]/connection for instance) You just can't ignore those configs
> >>when generating the sample config file.
> >>
> >>(sorry for self-promotion, I didn't want to rewrite my thoughts on this
> >>list)
> >>
> >>--
> >>Mathieu
> >
> >
> >_______________________________________________
> >OpenStack-operators mailing list
> >OpenStack-operators at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141210/6e7ed579/attachment.html>