OpenDev Migration Patch
This commit was bulk generated and pushed by the OpenDev sysadmins as a part of the Git hosting and code review systems migration detailed in these mailing list posts: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html Attempts have been made to correct repository namespaces and hostnames based on simple pattern matching, but it's possible some were updated incorrectly or missed entirely. Please reach out to us via the contact information listed at https://opendev.org/ with any questions you may have.
|1 month ago|
|examples||3 years ago|
|giftwrap||2 years ago|
|scripts||4 years ago|
|.gitignore||4 years ago|
|.gitreview||1 month ago|
|.rubocop.yml||5 years ago|
|.travis.yml||5 years ago|
|CHANGELOG.md||3 years ago|
|Dockerfile||4 years ago|
|LICENSE||5 years ago|
|Makefile||5 years ago|
|README.md||3 years ago|
|Vagrantfile||4 years ago|
|giftwrap.png||3 years ago|
|requirements.txt||3 years ago|
|setup.cfg||3 years ago|
|setup.py||5 years ago|
|test-requirements.txt||1 year ago|
|tox.ini||3 years ago|
A tool for creating bespoke system-native OpenStack artifacts.
Anyone running OpenStack at scale typically crafts their own software distribution mechanism. There may be many reasons for this, but chief among them seem to be the desire to ship security patches, deliver custom code, lock their releases at a revision of their choosing, or just generally stay closer to trunk.
Unfortunately, until now, there has been no easy way to accomplish this. If one were to decide to utilize distribution packages they are now at the mercy of the distribution itself - who’s release timeline may not be the same as yours.
On the other hand, if one were to install directly from source, they will encounter a slightly different problem. Because the Python community is quite active, and because OpenStack, in many regards, does not strictly call out it’s dependencies, one may build OpenStack with incompatible (or at least unknown) dependencies. Even worse, one may even find that OpenStack components may be different on different nodes in the cluster.
Long story short, this sucks.
Inspired by some of the work I had done to create omnibus-openstack, I decided to do things slightly differently. While omnibus-openstack met most of my needs there were a few problems. First, the project was written in Ruby. While this, in my opinion, is not a problem, this makes it somewhat unapproachable to a vast segment of OpenStack users and operators. Second, the packages are HUGE. Again, while this may not be a real problem for many, the reason they are huge is that they manage all of the system level dependencies as well: things like openssl, libvirt, etc. These are not things that many folks typically want to be responsible for managing; whether for security or even complexity reasons.
With all of this in mind, it seemed to me that we already had all of the information that we already needed to create system-native (ie. rpm, deb, and even Docker) artifacts that had already been tested with the Gerrit CI infrastructure. Hence, giftwrap.
$ pip install . $ python setup.py install $ giftwrap -h
$ git clone https://github.com/openstack/giftwrap.git $ vagrant up
$ make test
giftwrap is pretty simple. The basic flow is something like this:
giftwrap build -m <manifest> [-v <version>]
This shows how to use docker-in-docker to build packages really fast. the example shows doing it within the provided vagrant instance. but this is for illustration purposes, it should be runnable from any machine with docker installed.
Build a giftwrap docker container like this:
$ docker build -t bluebox/giftwrap .
Run the giftwrap docker image and map in your docker socket and your manifest file:
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /vagrant/sample.yml:/tmp/manifest.yml bluebox/giftwrap $ docker images openstack-9.0 REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE openstack-9.0 bbc6 44c37c8d9672 10 minutes ago 499.5 MB
|Authors||John Dewey (firstname.lastname@example.org)|
|Craig Tracey (email@example.com)|
|Paul Czarkowski (firstname.lastname@example.org)|
|Copyright||Copyright © 2014, John Dewey|
|Copyright © 2014, Craig Tracey|
|Copyright © 2014, Paul Czarkowski|
Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.