Public Cloud Image Change Information

Share
Share

With the last push of our Public Cloud images we also enabled the publishing of image change information. We’ve had numerous requests to make change data available when images get published and we are happy to share that this data is now available.

Bottom Line On Top

Change information is published and accessible via https:// protocol using predictable URLs. The data is using HTML as the data format to satisfy the needs for content presentation in a browser and being integrated into automation.

For those using a browser the change data is linked from pint.suse.com which presents the pint data in browsable format. For images that have change information a “Changelog” link is shown in the table and this link will take you to the change data.

For those that prefer command line tools the pint client will present an entry called changeinfo in the XML or JSON data that contains the link to the change data for a given image. The link will take you to an index page that has links to the data set for 4 categories, details about the categories can be found in the “How Did We Get There” section below.

The change data urls are composable/predictable as follows

https://publiccloudimagechangeinfo.suse.com/$FRAMEWORK/$IMAGE_NAME

where $FRAMEWORK is one of the frameworks where we publish images and matches the names for the pint command line tool, i.e. one of

alibaba
amazon
google
microsoft
oracle

and image name is the name found in the pint data with the name attribute. With the base URL established, the information for each category is found with

  1. image_changes.html
    1. For image setup changes
  2. cve_fixes.html
    1. For a list of CVEs fixed in this image compared to the previous one. All of these entries are cross linked to the SUSE published CVE data.
  3. package_version_changes.html
    1. The list of all the packages that had version changes compared to the last image and the version in the image.
  4. package_changelogs.html
    1. The concatenated changelog of all the packages that had changes in this image compared to the previously released image.

For example

https://publiccloudimagechangeinfo.suse.com/google/sles-12-sp5-byos-v20210209/package_changelogs.html

produces the concatenated changelog of all the changed packages in the image with the name sles-12-sp5-byos-v20210209 when compared to the previous image (sles-12-sp5-byos-v20201210).

Going forward change data publishing will be part of every image release. There is some information that we want to publish and that we are still working on. Today collecting information about image configuration changes is not possible as there is an information gap. That said, we are working on closing the information gap by moving our image descriptions to GitHub. At some point in the not too distant future keg will be the tool to use to compose image definitions from keg-recipes . Once we have this in place the change information will start to contain information about image setup changes. In addition with keg & keg-recipes our image descriptions will become public and as such it gets a lot easier to build your own derivatives. For now the image change data only contains added and removed packages.

With the new data you can now pin point an image that contains a sepcific change you may be looking for.

How Did We Get There?

Images are a conglamoration of things and as such the meaning of “changelog” is not necessarily as straight forward as it may sound. Therefore our first task was to define the meaning of image changes and classify what kind of data exists and how it can be collected and presented. Another aspect of the change data generation is that, as the name implies, we need to present data that indicates changes between two released images, i.e. two states at particular points in time. With the problem space somewhat sandboxed we went to work to see what we could come up with.

What Does Image Change Information Mean?

Our first problem was to define what image change information actually means. There is obviously the content of the image that changes but even that can be sliced and diced in certain ways and generating one big blog of data didn’t seem very useful. After a number of discussions we settled on four categories:

  1. Image setup changes
    1. This category describes any changes that may have taken place in the image setup. For example a new service was enabled, kernel parameters were changed and stuff like this. This also includes package additions or removals.
  2. Security information
    1. A keen interest exists for people to find out which particular CVEs got fixed in a given image release. And given that we already publish details about CVEs  naturally a cross link to individual CVEs to obtain their description and details should exist.
  3. Package information
    1. While looking at particular package version numbers has it’s pros and cons having package version information is certainly useful in certain circumstances, even if it is the build number of a package.
  4. Changelog information
    1. Last but not least for anyone looking for a specific change it is interesting to process the changelog information and as such we decided that a concatenated changelog would be the fourth category of interesting change data.

With the categories determined we needed to set out and collect the proper data to be presented. This led us to

The Asychronus Build And Release Problem

All images that get released are built with a SUSE internal instance of the Open Build Service using kiwi . One of the great features of OBS is that it keeps track of dependencies and automatically rebuilds things when dependencies change. For images that means whenever a package that is included in an image gets updated the image gets rebuilt. As such our images are in a more or less constant state of getting rebuilt. Depending on the image release cycle any image build may get released on any given day. So in order to generate change information we needed to know which build was released for any of the images we publish. This required a change in process and some tooling to support the change information generation between the previously released image and the current build.

With the categories defined and the data collection sorted out it was a matter of presentation and seting up the necessary infrastructure to make the data accessible.

Share
(Visited 1 times, 1 visits today)

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet

Robert Schweikert
773 views