Hey y'all,
To avoid cross-posting, please inform your -infra / -operations buddies about
this post.
We've just started thinking about where notification schema files should live
and how they should be deployed. Kind of a tricky problem. We could really use
your input on this problem ...
The assumptions:
1. Schema files will be text files. They'll live in their own git repo
(stackforge for now, ideally oslo eventually).
2. Unit tests will need access to these files for local dev
3. Gating tests will need access to these files for integration tests
4. Many different services are going to want to access these files during
staging and production.
5. There are going to be many different versions of these files. There are
going to be a lot of schema updates.
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.
b. In production, each openstack service could expose the schema files via
their REST API, but that doesn't help gating tests or unit tests. Also, this
means every service will need to support exposing schema files. Big
coordination problem.
c. In production, We could add an endpoint to the Keystone Service Catalog to
each schema file. This could come from a separate metadata-like service. Again,
yet-another-service to deploy and make highly available.
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?
Personally, I'm leaning towards option D but I'm not sure what the implications
are.
We're early in thinking about these problems, but would like to start the
conversation now to get your opinions.
Look forward to your feedback.
Thanks
-Sandy
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
