[openstack-dev] Where should Schema files live?

Eoghan Glynn eglynn at redhat.com
Fri Nov 21 15:03:49 UTC 2014



> >> Some problems / options:
> >> a. Unlike Python, there is no simple pip install for text files. No
> >> version control per se. Basically whatever we pull from the repo. The
> >> problem with a git clone is we need to tweak config files to point to a
> >> directory and that's a pain for gating tests and CD. Could we assume a
> >> symlink to some well-known location?
> >>     a': I suppose we could make a python installer for them, but that's a
> >>     pain for other language consumers.
> 
> >Would it be unfair to push that burden onto the writers of clients
> >in other languages?
> >
> >i.e. OpenStack, being largely python-centric, would take responsibility
> >for both:
> >
> >  1. Maintaining the text versions of the schema in-tree (e.g. as json)
> >
> >and:
> >
> >  2. Producing a python-specific installer based on #1
> >
> >whereas, the first Java-based consumer of these schema would take
> >#1 and package it up in their native format, i.e. as a jar or
> >OSGi bundle.
> 
> Certainly an option. My gut says it will lead to abandoned/fragmented
> efforts.
> If I was a ruby developer, would I want to take on the burden of maintaining
> yet another package?
> I think we need to treat this data as a form of API and there it's our
> responsibility to make easily consumable.
> 
> (I'm not hard-line on this, again, just my gut feeling)

OK, that's fair.

[snip]
> >> d. Should we make separate distro packages? Install to a well known
> >> location all the time? This would work for local dev and integration
> >> testing and we could fall back on B and C for production distribution. Of
> >> course, this will likely require people to add a new distro repo. Is that
> >> a concern?
> 
> >Quick clarification ... when you say "distro packages", do you mean
> >Linux-distro-specific package formats such as .rpm or .deb?
> 
> Yep.

So that would indeed work, but just to sound a small note of caution
that keeping an oft-changing package (assumption #5) up-to-date for
fedora20/21 & epel6/7, or precise/trusty, would involve some work.

I don't know much about the Debian/Ubuntu packaging pipeline, in
particular how it could be automated.

But in my small experience of Fedora/EL packaging, the process is
somewhat resistant to many fine-grained updates.

Cheers,
Eoghan



More information about the OpenStack-dev mailing list