watch out for architecture dependent charms

Clint Byrum clint at ubuntu.com
Wed Nov 30 18:30:08 UTC 2011


Excerpts from Gustavo Niemeyer's message of Wed Nov 30 09:17:22 -0800 2011:
> Hi Mark,
> 
> > Just a note for charm-craft (writing, reviewing, and testing)... ran across
> > an architecture-dependent bug while reviewing a charm.  No real surprise...
> > the charm downloads binary bits.
> >
> > Charm authors/reviewers, please watch out for such things.
> 
> That's a good point, and a known edge we have to sort out eventually.
> 
> > Our automated test framework should at least tag charms according to which
> > architectures they pass tests against. (?)
> 
> The responsibility should probably reversed: the testing framework
> should run tests only on the architectures that the charms have been
> _declared_ to run on.
> 
> We still have to nail down details of how the architecture tagging
> works, because this impacts other areas too. For instance, we need to
> deploy the charm in the right machine, of course.
> 
> We covered some strategies for that at UDS, with the file-get idea,
> but it needs to be polished up.
> 

I see your point, that it would be easier to handle testing if all charms
explicitly specify their known working architectures. But Ubuntu just
added a new architecture for precise (armhf) and we'd have to go through
and add this tag to all charms, then remove it from the ones that fail.
This sounds a bit backwards.

This feels like a constraint tag, so if none is specified, there are no
constraints. We should actually make "architecture" one of the required
constraints that all providers expose for their pools of machines. For
local, its the local machine's arch capabilities (x86_64 machines can
expose both i386 and x86_64). Cobbler has the arch in the profile. EC2
implies it from the instance type.

If a test fails because there's no binary for arm, then we can add the
constraint, something like:

!arch(armel)

or maybe like this:

tag(arch-i386) | tag(arch-x86-64)

For now.. without this capability in juju, we can simply make sure that
charms do the right thing and detect their architecture, then error out
sensibly. With packages, this is already handled.. and yet another reason
to suggest all binaries be packaged when reviewing a charm.



More information about the Juju mailing list