juju-core on i386
David Cheney
david.cheney at canonical.com
Fri Apr 19 23:00:41 UTC 2013
None here captain.
https://code.launchpad.net/~dave-cheney/+recipe/juju-core-daily
If the release-public-tools script does not already understand 386, it
can be whipped into shape quickly.
On 20/04/13 02:01, William Reade wrote:
> On Fri, 2013-04-19 at 21:42 +1000, David Cheney wrote:
>>> Do we have 32-bit binaries for Mongo as well? The other limiter is
>>> that the client defaults the target to the same architecture, and at
>>> least until now you couldn't run a 32-bit state server.
>
> Not any more: target selection should be entirely determined by the
> available tools (which are then used to filter reasonable images).
>
>> Mongo is not needed on the client. We do have mongodb-server binaries
>> for 386 state servers. However, all state servers are hard coded to use
>> a amd64 image (I just checked, William says this is true)
>
> I clearly fail at communication.
>
> If, on EC2, after all constraints etc have been applied, there's still a
> choice of arches available, we default to amd64. But if we only had i386
> tools, or if we specified arch=i386 in constraints, it should work fine.
>
> Openstack currently assumes that the default-image-id is precise/amd64,
> so it'll refuse to bootstrap/startinstance if suitable tools for that
> image aren't available (eg if you've uploaded tools from i386). This
> will be resolved once clouddata handling lands (which won't be long, I
> hope).
>
> MAAS currently picks an arbitrary arch from those available, which has
> been working by coincidence, but will not do so forever. Fixing this is
> not challenging but has not yet been done.
>
> ISTM that, despite the spotty support in practice, we should make i386
> tools available across the board: I don't think it will make anyone's
> experience any worse, and it'll make some peoples' better.
>
> Dissent?
>
> Cheers
> William
>
>
More information about the Juju
mailing list