Open Stack

On Wed, Dec 10, 2014 at 11:16 AM, Fischer, Matt <matthew.fischer at twcable.com
> wrote:

>
>
>   From: Anne Gentle <anne at openstack.org>
> Date: Wednesday, December 10, 2014 at 8:41 AM
> To: Michael Dorman <mdorman at godaddy.com>
> Cc: "openstack-operators at lists.openstack.org" <
> openstack-operators at lists.openstack.org>
> Subject: Re: [Openstack-operators] Packaging sample config versions
>
>
>
> 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/
>
>  I don’t see full sample configs in here, just more focused “example”
> configs, am I missing it? Does the generated content include everything
> from config.py in each project? I’m asking because I’ve seen a few places
> where the documented defaults and whats in the code do not match.
>
>  When I upgrade puppet versions, like I’m doing now from the icehouse
> puppet branches, its very important for me to know:
>
>    1. what has a new default value
>    2. whether we were previously using the old default value
>    3. what lines change/move/got renamed
>    4. what is deprecated
>
>  The docs do a good job of most of these, but I cannot beat a well
> maintained full sample config.
>
>  Here are a few small examples of places where the docs and code didn’t
> match for Juno, hence my questions about how the docs were generated:
>
>  https://bugs.launchpad.net/openstack-manuals/+bug/1380778
>  https://bugs.launchpad.net/openstack-manuals/+bug/1380813
>
>
At first glance, I don't know what's going on there, so I'll investigate
further and comment in the bugs. Thanks Matt for logging.

I'm not sure I exactly understand the difference between sample configs and
example configs - my best guess is:
sample configs: complete .conf file with some options enabled that will
work and all the rest of the options in the file but commented out
including defaults and description?
example configs: working .conf file that doesn't contain all the options.

Is that accurate?


>  Note: I also filed two bugs against keystone itself for having default
> values that were deprecated, so its not perfect either.
>
>  >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
>>
>
>
> ------------------------------
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141211/b3dfeea6/attachment.html>