Open Stack

On Monday, 2 October 2017 13:28:17 CEST Thomas Goirand wrote:
> On 09/28/2017 04:50 PM, Jesse Pretorius wrote:
> > There’s some history around this discussion [1], but times have changed
> > and the purpose of the patches I’m submitting is slightly different [2]
> > as far as I can see – it’s a little more focused and less intrusive.
> > 
> >  
> > 
> > The projects which deploy OpenStack from source or using python wheels
> > currently have to either carry templates for api-paste, policy and
> > rootwrap files or need to source them from git during deployment. This
> > results in some rather complex mechanisms which could be radically
> > simplified by simply ensuring that all the same files are included in
> > the built wheel. Distribution packagers typically also have mechanisms
> > in place to fetch the files from the source repo when building the
> > packages – including the files through pbr’s data_files for packagers
> > may or may not be beneficial, depending on how the packagers do their
> > build processes.
> > 
> >  
> > 
> > In neutron [3], glance [4], designate [5] and sahara [6] the use of the
> > data_files option in the files section of setup.cfg is established and
> > has been that way for some time. However, there have been issues in the
> > past implementing something similar – for example in keystone there has
> > been a bit of a yoyo situation where a patch was submitted, then reverted.
> > 
> >  
> > 
> > I’ve been proposing patches [7] to try to make the implementation across
> > projects consistent and projects have, for the most part, been happy to
> > go ahead and merge them. However concern has been raised that we may end
> > up going through another yo-yo experience and therefore I’ve been asked
> > to raise this on the ML.
> > 
> >  
> > 
> > Do any packagers or deployment projects have issues with this
> > implementation? If there are any issues, what’re your suggestions to
> > resolve them?
> 
> I still have the issue that adding stuff in etc, at packaging time, push
> them in /usr/etc, which is obviously wrong. We tried to push for a PBR
> patch, but failed, as Robert Collins wrote it had to be fixed in
> setuptools. Which is why all patches have been reverted so far.
> 
> While I may agree with Robert, I think we had to choose for a pragmatic
> (even temporary) solution, and I don't understand why it's been years
> that this stays unfixed, especially when we have an easy solution. [1]
> 
> So, until that is fixed, please do not propose this type of patches.

Why not? Even if it does not fix the issue for proper installations,
- it does not provent people from copying the files somewhere else (it 
happened in sahara for how long I can remember, we have been using data_files)
- it fixes the deployment when the package is installed in a virtualenv;
- it introduces consistency: the day data_files starts to do the right thing, 
everything will work; if it's not possible to fix it with data_files, it's 
easy to spot which files should be fixed because all handled by data_files.

So definitely go for it.

Ciao
-- 
Luigi