Excerpts from Clint Byrum's message on 14/10/2014 23:38:46: <snip> > > > > Regarding the process of building base images, the currently documented way > > [1] of using diskimage-builder turns out to be a bit unstable sometimes. > > Not because diskimage-builder is unstable, but probably because it pulls in > > components from a couple of sources: > > #1 we have a dependency on implementation of the Heat engine of course (So > > this is not pulled in to the image building process, but the dependency is > > there) > > #2 we depend on features in python-heatclient (and other python-* clients) > > #3 we pull in implementation from the heat-templates repo > > #4 we depend on tripleo-image-elements > > #5 we depend on os-collect-config, os-refresh-config and os-apply-config > > #6 we depend on diskimage-builder itself > > > > Heat itself and python-heatclient are reasonably well in synch because > > there is a release process for both, so we can tell users with some > > certainty that a feature will work with release X of OpenStack and Heat and > > version x.z.y of python-heatclient. For the other 4 sources, success > > sometimes depends on the time of day when you try to build an image > > (depending on what changes are currently included in each repo). So > > basically there does not seem to be a consolidated release process across > > all that is currently needed for software config. > > > > I don't really understand why a "consolidated release process across > all" would be desired or needed.
Well, all pieces have to fit together so everything work. I had many situations where I used the currently up-to-date version of each piece but something just did not work. Then I found that some patch was in review on any of those, so trying a few days later worked. I would be good for users to have one verified package of everything instead of going thru a trial and error process. Maybe this is going to improve in the future, since so far or until recently a lot of software config was still work in progress. But up to now, the image building has been a challenge at some time. > > #3 is pretty odd. You're pulling in templates from the examples repo? We have to pull in the image elements and hooks for software config from there. > > For #4-#6, those are all on pypi and released on a regular basis. Build > yourself a bandersnatch mirror and you'll have locally controlled access > to them which should eliminate any reliability issues. So switching from git repo based installed as described in [1] to pypi based installs, where I can specify a version number would help? Then what we would still need is a set of version for each package that are verified to work together (my previous point). > > > The ideal solution would be to have one self-contained package that is easy > > to install on various distributions (an rpm, deb, MSI ...). > > Secondly, it would be ideal to not have to bake additional things into the > > image but doing bootstrapping during instance creation based on an existing > > cloud-init enabled image. For that we would have to strip requirements down > > to a bare minimum required for software config. One thing that comes to my > > mind is the cirros software config example [2] that Steven Hardy created. > > It is admittedly no up to what one could do with an image built according > > to [1] but on the other hand is really slick, whereas [1] installs a whole > > set of things into the image (some of which do not really seem to be needed > > for software config). > > The agent problem is one reason I've been drifting away from Heat > for software configuration, and toward Ansible. Mind you, I wrote > os-collect-config to have as few dependencies as possible as one attempt > around this problem. Still it isn't capable enough to do the job on its > own, so you end up needing os-apply-config and then os-refresh-config > to tie the two together. > > Ansible requires sshd, and python, with a strong recommendation for > sudo. These are all things that pretty much every Linux distribution is > going to have available. Interesting, I have to investigate this. Thanks for the hint. > > > > > Another issue that comes to mind: what about operating systems not > > supported by diskimage-builder (Windows), or other hypervisor platforms? > > > > There is a windows-diskimage-builder: > > https://git.openstack.org/cgit/stackforge/windows-diskimage-builder Good to know; I wasn't aware of it. Thanks! > > diskimage-builder can produce raw images, so that should be convertible > to pretty much any other hypervisor's preferred disk format. > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev