Excerpts from Steve Baker's message on 14/10/2014 23:52:41: <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. > > 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).
> > Building an image from git repos was the best chance of having a > single set of instructions which works for most cases, since the > tools were not packaged for debian derived distros. This seems to be > improving though; the whole build stack is now packaged for Debian > Unstable, Testing and also Ubuntu Utopic (which isn't released yet). > Another option is switching the default instructions to installing > from pip rather than git, but that still gets into distro-specific > quirks which complicate the instructions. Until these packages are > on the recent releases of common distros then we'll be stuck in this > slightly awkward situation. Yeah, I understand that the current situation is probably there because we are so close to the point where the features get developed. So hopefully this will improve and stabilize in the future. > > I wrote a cloud-init boot script to install the agents from packages > from a pristine Fedora 20 [3] and it seems like a reasonable > approach for when building a custom image isn't practical. Somebody > submitting the equivalent for Debian and Ubuntu would be most > welcome. We need to decide whether *everything* should be packaged > or if some things can be delivered by cloud-init on boot (os- > collect-config.conf template, 55-heat-config, the actual desired > config hook...) Thanks for the pointer. I'll have a look. I think if we can put as little requirements on the base image and do as much as possible at boot, that would be good. If help is needed for getting this done for other distros (and for Windows) we can certainly work on this. We just have to agree and be convinced that this is the right path. > > I'm all for there being documentation for the different ways of > getting the agent and hooks onto a running server for a given > distro. I think the hot-guide would be the best place to do that, > and I've been making a start on that recently [4][5] (help > welcome!). The README in [1] should eventually refer to the hot- > guide once it is published so we're not maintaining multiple build > instructions. I'll have a look at all the pointers. Agree that this is extremely useful. BTW: the unit testing work you started on the software config hooks will definitely help as well! > > Another issue that comes to mind: what about operating systems not > supported by diskimage-builder (Windows), or other hypervisor platforms? > The Cloudbase folk have contributed some useful cloudbase-init > templates this cycle [6], so that is a start. I think there is > interest in porting os-*-config to Windows as the way of enabling > deployment resources (help welcome!). Yes, I've seen those templates. As long as there is an image that work with them, this is great. I have to look closer into the Windows things. > > Any, not really suggestions from my side but more observations and > thoughts. I wanted to share those and raise some discussion on possible > options. > Thanks Thomas, that was useful. > > cheers > > > [1] > https://github.com/openstack/heat-templates/blob/master/hot/ > software-config/elements/README.rst > [2] > https://github.com/openstack/heat-templates/tree/master/hot/ > software-config/example-templates/cirros-example > [3] https://review.openstack.org/#/c/119282/1/hot/software-config/ > example-templates/pristine-image/install_config_agent.sh > [4] http://git.openstack.org/cgit/openstack/openstack-manuals/tree/ > doc/hot-guide/source/software_deployment.rst > [5] https://review.openstack.org/#/c/127109/ > [6] http://git.openstack.org/cgit/openstack/heat-templates/tree/hot/Windows > _______________________________________________ > 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