[RFC] Morph branch-from-image
sam.thursfield at codethink.co.uk
Tue Jan 29 12:44:32 GMT 2013
On 01/29/2013 12:11 PM, Richard Maw wrote:
> On Tue, Jan 29, 2013 at 11:28:30AM +0000, Sam Thursfield wrote:
>> On 01/28/2013 04:18 PM, Richard Maw wrote:
>>> The basic behaviour of given an image, create a System Branch petrified
>>> at the point where it was built is well specified, but I still have some
>>> further questions about how it should work before I get too tied to an
>>> implementation which may turn out to be wrong.
>>> 1. How should the baserock metadata be given.
>>> a. Path to Disk image
>>> branch-from-image mounts it to find the metadata.
>>> b. Path to directory
>>> branch-from-image globs for metadata in the directory
>>> c. List of paths to metadata files
>>> branch-from-image leaves finding metadata up to caller
>> Initially I pictured this command being run on the image itself (ie.
>> get the source code for the actual system you're running), in which
>> case you don't need to provide any parameters. Supporting both that
>> case (no parameters) and getting source for a different system image
>> (pass the path to the system image) seems like all we need.
> Ah, so the path to directory option, but defaulting to /baserock, good
I was thinking the path to the image itself, actually. The metadata in
/baserock will always be inside the disk image, so if we require a path
to a metadata directory when the user wants to check out the code for a
non-running image, we're making them loopback-mount the disk image
manually before they run the command every time.
>>> 3. Does the caller specify the branch's root repository and name?
>>> The branch the System was built from and its repository is stored
>>> in the metadata, but if it doesn't exist any more, it will need a
>>> fallback anyway.
>>> Specifying gives it a nice symmetry with `morph branch` which
>>> defaults to branching from master, but can be told a different
>>> branch instead. With it given you're saying branch as this but from
>>> this image instead of master.
>> It seems that in the .meta files we store the full URLs rather than
>> the keyed URLs of the git repos. That's a good thing (otherwise
>> different repo-alias configs would make everyone confused, all the
>> time). However, if we're checking out a system branch which someone
>> is going to do a lot of work on (if all they want to do is go "what
>> code am I running" maybe this doesn't matter) we really want to
>> restore the repo aliases so that git://git.baserock.org/baserock
>> becomes baserock: etc.
>> Perhaps it's finally time to write the code to do this :)
> That's a different issue to the one described, though it is addressed
> later. This is more about what the branch should be called and where is
> its root repository.
> This could be the same as it was built from, but you may not want it
> to be, and the branch may no longer exist.
If the root repository no longer exists, I think the user gets to keep
all of the pieces. For the branch name, I'm starting to think that we
should let the user specify it. /etc/os-release can tell them the branch
the system was originally built from so they can specify the same branch
name if they want.
>>> 5. When should it give up trying to make the branch?
>>> a. When the commit the System was built from does not exist?
>>> b. When the branch the System was built from does not have a similar
>>> This could be expensive to work out and probably not worth the
>>> c. When the branch does not exist at all?
>>> At this point the morphologies can be regenerated from the
>>> metadata, but it's going to be complicated.
>> If we're using a feature branch workflow, it'll be possible for the
>> branch to have been deleted but the commits themselves to have been
>> merged into a different branch. So I think we should mainly try to
>> honour the SHA1s.
>> Have you come up with actual usage scenarios for this yet?
> Rob Taylor's suggestion yesterday was that it's for the case of:
> 1. You have a problem with your system.
> 2. You branch from the System.
> 3. You fix the bug in your branch.
> 4. You send the patch upstream.
> My thoughts have been revolving around the use case of needing to
> reproduce a build, at which point it's just branch it then build again.
> This could be required if you broke your system, but you still have
> access to /baserock
In the first case the user wants their own personal branch name; in the
second case they might want to reuse the original branch name or a
personal variant. I'm starting to think we should always allow the user
to specify the branch name (and you're right, it does create a nice
symmetry with 'morph branch')
>> I think that would help us decide whether it's more useful to guess a
>> branch name by following parent commits until we get to a ref,
> This wouldn't work, since the tip of the branch has the ref, and
> following parents leads to the root.
> I think you'd have to start from all the tips, and work out which branch
> has the shortest distance to the commit.
That doesn't sound fun at all.
>>> 8. Should morph attempt to convert expanded repository urls back to
>>> their aliases?
>>> The metadata only contains the expanded urls, it's possible to work
>>> backwards using your repo aliases, but given how flexible the aliases
>>> are, it's strictly a search of all possible substrings of the
>>> repository url passed to every known repo-alias.
>> Yes :) It would make some system-branch commands more user friendly
>> too if we had code to do this.
> One problem with this is that your repo-aliases may not be the same as
> they were when the image was built, so getting back to the originals may
> not be possible, and it could take a while to find this out.
I don't think that this would be a problem in the real world. Changing
baserock: is not something we want to do often. (I'd like to change it,
so that I stop having to write baserock:baserock/morphs everywhere, but
that's beside the point).
I don't think it would be slow, either. I have 5 repo aliases in my
morph.conf currently, so 10 possible patterns to match a candidate URL
More information about the baserock-dev