| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This commit also disables the cross-bootstrap test, as the
cross-bootstrap plugin needs rewriting to use OSTree.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit 826e49e2791d4c45e4902396a4a59836290dc175.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes two issues: first, downloads were being put into the default
TMPDIR, which is an in-memory file system. When large artifacts are put
into /tmp such as gcc-devel, which is over 400MB, I found that my system
became unusable due to out of memory / swap death. Ideally we'd fix
Linux's memory management, but a more practical solution for now is to
download the files to the artifact cache directory. I've not noticed any
loss in speed from this change.
Second, temporary files should always cleaned up now, even when there
are errors during transfer or extraction.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this info was just in the log file, but I think it should be
on the console too.
Also, the 'Downloading xx as tarball' message would appear even when
there was no tarball to download, which was a bit weird.
Output with `morph build --verbose` now looks like this:
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Fetching to local cache: artifact stage2-gcc-locale
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Downloading stage2-gcc-locale as a tarball.
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Committing stage2-gcc-locale to artifact cache at 14ae4efeeaeea43f8a4f9198172ca9961f343cde663ec98e7061259d6542c35a-locale.
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Fetching to local cache: artifact stage2-gcc-libs
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Downloading stage2-gcc-libs as a tarball.
2015-03-25 15:00:53 [Build 8/226] [stage2-gcc] Committing stage2-gcc-libs to artifact cache at 14ae4efeeaeea43f8a4f9198172ca9961f343cde663ec98e7061259d6542c35a-libs.
|
|
|
|
|
| |
The OSTree checkout uses hardlinks anyway, so this is thankfully now
redundant.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Its much harder to look at the contents of the artifact cache now that
they aren't stored by chunk name (just cache key and artifact suffix).
All of these were failing because they were trying to extract chunk
tarballs or locate and inspect artifacts, so just make sure the builds
themselves don't fail. The build-system tests are a lot of work to make
into yarns, as we'll need to build systems with actual tools in as far
as I can tell.
Also disable the cross-bootstrap test for now.
|
|
|
|
|
|
|
| |
The cross-bootstrap plugin is currently full of hacks, so it makes sense
to rewrite it properly rather than extending these hacks to work with
OSTree. I don't have time to do this right now, so disable the
cross-bootstrap yarn.
|
|
|
|
|
|
|
|
|
| |
OSTree can easily pull over HTTP. All that is necessary is to expose the
repo directory. This commit adds a simple HTTP server to do this in the
test suite. Actual implementations should use something better, like
lighttpd.
Also add some logging of the cache servers in this yarn to help debug.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that we have an OSTree artifact cache, the deploy plugin needs to use
that to get the system to be deployed. Due to the changes in how we store
systems, we need to get the contents of each stratum then put the system
delta on top of that.
This is still much quicker than unpacking stuff from tarballs.
|
|
|
|
|
|
|
| |
The API of the OSTree artifact cache is slightly different to that of the
old tarball cache, so adjust things accordingly. Also, only store the
files changed at system-construction-time rather than everything in
system artifacts.
|
| |
|
|
|
|
|
| |
This commit updates RemoteArtifactCache to enable it to interact with
a remote OSTree artifact cache.
|
| |
|
| |
|
|
|
|
|
|
| |
Change create_chunk to put the contents of an artifact into a directory
rather than storing them in a tarball, as we want to store chunks as
directory trees in OSTree rather than tarballs now.
|
|
|
|
|
|
| |
This avoids needing to pass the cache to the staging area since
lac.get returns a path to a directory tree rather than a file
handle now, so we also don't need to do any unpacking.
|
|
|
|
|
|
|
|
|
| |
We can't store devices nodes in OSTree, so we can't create them at
artifact build time and store them in the chunk artifacts anymore.
Instead, we should create them in the staging area when installing
an artifact with a source which has a morphology which defines
them into the staging area.
|
|
|
|
|
|
| |
Overlayfs is new in version 3.18 of the kernel, so add support for a
different implementation of a union/overlay filesystem in order to
allow morph to work on older kernels.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When deploying, configuration extensions are run against the unpacked
tarball of a system created by a build. If we are to use OSTree to
store systems (rather than tarballs) this will not be possible as the
result of `ostree checkout` would be read-only.
To solve this, we use overlayfs to mount the unpacked tarball
underneath a temporary directory somewhere, and run the configuration
extensions on that mount point. This means that the changes are
made in the temporary directory rather than directly on the tarball.
|
|
|
|
|
| |
This will allow us to cache systems as a list of chunks and a small
filesystem delta, rather than a massive tarball.
|
|
|
|
|
| |
In order to mount using overlayfs, fsutils.mount needs to take a
string of options to pass to the mount command.
|
|
|
|
| |
Change-Id: I1ffb63340d3facb608708d04a0a21c5a9e290c14
|
|
|
|
| |
Change-Id: I9344b9b80a6ec008715559390b63c9003f34bf90
|