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