Open Stack

>From: Eoghan Glynn [eglynn at redhat.com] Friday, November 21, 2014 11:03 AM
>> >> 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.

I think Doug's suggestion of keeping the schema files in-tree and pushing them to a well-known tarball maker in a build step is best so far. 

It's still a little clunky, but not as clunky as having to sync two repos. 

>[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.

Ah, good to know. So, if we go with the tarball approach, we should be able to avoid this. And it allows the service to easily service up the schema using their existing REST API. 

Should we proceed under the assumption we'll push to a tarball in a post-build step? It could change if we find it's too messy. 

-S