Open Stack

> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Date: 04/14/2016 04:53 PM
> Subject: Re: [openstack-dev] [all] [devstack] Adding example 
> "local.conf" files for testing?
> 
> 
> 
> On 4/14/2016 6:09 AM, Sean Dague wrote:
> > On 04/14/2016 05:19 AM, Markus Zoeller wrote:
> >>> From: Neil Jerram <Neil.Jerram at metaswitch.com>
> >>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>> <openstack-dev at lists.openstack.org>
> >>> Date: 04/14/2016 10:50 AM
> >>> Subject: Re: [openstack-dev] [all] [devstack] Adding example
> >>> "local.conf" files for testing?
> >>>
> >>> On 14/04/16 08:35, Markus Zoeller wrote:
> >>>> Sometimes (especially when I try to reproduce bugs) I have the need
> >>>> to set up a local environment with devstack. Everytime I have to 
look
> >>>> at my notes to check which option in the "local.conf" have to be 
set
> >>>> for my needs. I'd like to add a folder in devstacks tree which 
hosts
> >>>> multiple example local.conf files for different, often used setups.
> >>>> Something like this:
> >>>>
> >>>>       example-confs
> >>>>       --- newton
> >>>>       --- --- x86-ubuntu-1404
> >>>>       --- --- --- minimum-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf
> >>>>       --- --- --- serial-console-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf
> >>>>       --- --- --- live-migration-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf.controller
> >>>>       --- --- --- --- local.conf.compute1
> >>>>       --- --- --- --- local.conf.compute2
> >>>>       --- --- --- minimal-neutron-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf
> >>>>       --- --- s390x-1.1.1-vulcan
> >>>>       --- --- --- minimum-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf
> >>>>       --- --- --- live-migration-setup
> >>>>       --- --- --- --- README.rst
> >>>>       --- --- --- --- local.conf.controller
> >>>>       --- --- --- --- local.conf.compute1
> >>>>       --- --- --- --- local.conf.compute2
> >>>>       --- mitaka
> >>>>       --- --- # same structure as master branch. omitted for 
brevity
> >>>>       --- liberty
> >>>>       --- --- # same structure as master branch. omitted for 
brevity
> >>>>
> >>>> Thoughts?
> >>>
> >>> Yes, this looks useful to me.  Only thing is that you shouldn't need 
the
> >>
> >>> per-release subtrees, though; the DevStack repository already has
> >>> per-release stable/<release> branches, which you need to check out 
in
> >>> order to do a DevStack setup of a past release.  So I would expect 
the
> >>> local.confs for each past release to live in the corresponding 
branch.
> >>>
> >>> Regards,
> >>>     Neil
> >>
> >> My intention was to avoid that there is a folder "current" or "trunk"
> >> or similar, which doesn't get updated. That's the issue Steve talked
> >> about.
> >>
> >> The workflow could be, at every new cycle:
> >>      * create a new "release folder" (Newton, Ocata, ...)
> >>      * copy the "setup folders" (minimum-setup, ...) to the new 
folder
> >>      * clean up the "local.conf" file(s) of deprecated options
> >>      * delete a "release folder" if the release is EOL
> >>
> >> I also assume that this would make potential backports easier.
> >
> > I think this would be useful, and accepted easily.
> >
> > I *don't* think we want per release directories. Because it confuses 
the
> > issue on whether or not devstack master can install liberty (which it
> > can't).
> >
> > Every local.conf should include a documentation page as well that
> > describes the scenario, which means these would be easy to snag off 
the
> > web docs.
> >
> >    -Sean
> >
> 
> +1 to add example scenarios (I have a copy of a basic neutron + ovs that 

> I got from a co-worker) and -1 on release-specific directories, we don't 

> need them as pointed out already, that's what the branches are for in 
> the git repo. The trunk local.confs should be updated naturally as 
> people try to use them and hit issues.
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 


Let me know what you think: https://review.openstack.org/#/c/305967/