Use juju-mongodb when the package is available

[Curtis Hovey]

juju-mongodb is ready for use with trusty. James Page suggests that jujud install juju-mongodb when the package is available, then fallback to mongodb-server. This allows us to backport jujuj-mongodb in the future.

Fixing this issue may be an opportunity to address bug 1240667. As I understand it, that bug wants the rules to change when selecting mongodb-server to ensure the version comes from the cloud-archive (because the cloud-archive should have a lower priority)

[Curtis Hovey (sinzui)]

This work needs to be done to unblock the enablement of new archs. unittests and experimental changes are blocked because juju is hard coded to depend on/install mongodb-server

[Curtis Hovey (sinzui)]

 juju-mongodb is partially enabled in 1.17.4 The db is used when it is present on the host. Juju will install the wrong db (mongodb-server) when left to it's own devices.

[dann frazier (dannf)]

On Wed, Mar 5, 2014 at 6:32 AM, Curtis Hovey <email address hidden> wrote:
> juju-mongodb is partially enabled in 1.17.4 The db is used when it is
> present on the host. Juju will install the wrong db (mongodb-server)
> when left to it's own devices.

Does that imply a workaround? If so, I'd be interested so I could
continue to make progress.

To be clear, the specific issue I'm seeing is that the 1.17.4
bootstrap code seems to fail if it cannot install mongodb-server on
the bootstrap node.
This works fine on x86 since it *can* install mongodb-server. But, if
I hack the code to c.AddPackage("juju-mongodb") instead, bootstrapping
using a trusty/amd64 image begins to fail (see below). I'm guessing
there's more code needed to startup and configure this alternate
server.

$ juju bootstrap
Launching instance
 - i-6dd2eb4c
Waiting for address
Attempting to connect to ec2-184-73-95-66.compute-1.amazonaws.com:22
Attempting to connect to ip-10-178-35-82.ec2.internal:22
Attempting to connect to 184.73.95.66:22
Attempting to connect to 10.178.35.82:22
Logging to /var/log/cloud-init-output.log on remote host
Running apt-get update
Running apt-get upgrade
Installing package: git
Installing package: cpu-checker
Installing package: bridge-utils
Installing package: rsyslog-gnutls
Installing package: juju-mongodb
Fetching tools: curl -o $bin/tools.tar.gz
'https://juju-dist.s3.amazonaws.com/tools/releases/juju-1.17.4-trusty-amd64.tgz'
Starting MongoDB server (juju-db)
Bootstrapping Juju machine agent
ERROR bootstrap failed: rc: 1
Stopping instance...
ERROR rc: 1

[Curtis Hovey (sinzui)]

There is no work-around for this issue. This is bug 1286279.

[Mark Ramm (mark-ramm)]

Bumping to critical because it is blocking non-intel archetecture support.

[Dave Cheney (dave-cheney)]

As of this morning this is not working, and is not working in a confusing way.

Previously juju bootstrap -e local --upload-tools would abort when /usr/bin/mongod was missing. The suggested message would ask you to install the wrong package, but we knew that already.

As of revno 2416, bootstrap no longer aborts when /usr/bin/mongod is missing, however bootstrap fails because mongodb never starts

ubuntu@winton-02:~/src/launchpad.net/juju-core$ cat /etc/init/juju-db-ubuntu-local.conf
description "juju state database"
author "Juju Team <email address hidden>"
start on runlevel [2345]
stop on runlevel [!2345]
respawn
normal exit 0

limit nofile 65000 65000
limit nproc 20000 20000

exec /usr/bin/mongod --auth --dbpath=/home/ubuntu/.juju/local/db --sslOnNormalPorts --sslPEMKeyFile '/home/ubuntu/.juju/local/server.pem' --sslPEMKeyPassword ignored --bind_ip 0.0.0.0 --port 37017 --noprealloc --syslog --smallfiles
ubuntu@winton-02:~/src/launchpad.net/juju-core$ file /usr/bin/mongod
/usr/bin/mongod: ERROR: cannot open `/usr/bin/mongod' (No such file or directory)

[Curtis Hovey (sinzui)]

juju-mongodb support was removed several revisions ago. hacks like symlinks to the installed juju-mongodb are required to make juju think a monogodb-server is installed.

Proper juju-mongodb support will be added at the state-server level. The feature was reverted because the cli assumed that the local presence of juju-mongodb meant that it was also on the bootstrap node.

[Dave Cheney (dave-cheney)]

well, bugger.

On Sat, Mar 15, 2014 at 10:03 AM, Curtis Hovey <email address hidden> wrote:

> juju-mongodb support was removed several revisions ago. hacks like
> symlinks to the installed juju-mongodb are required to make juju think a
> monogodb-server is installed.
>
> Proper juju-mongodb support will be added at the state-server level. The
> feature was reverted because the cli assumed that the local presence of
> juju-mongodb meant that it was also on the bootstrap node.
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: MOAR JUJU SPAM!
> https://bugs.launchpad.net/bugs/1271937
>
> Title:
> Use juju-mongodb when the package is available
>
> Status in juju-core:
> In Progress
>
> Bug description:
> juju-mongodb is ready for use with trusty. James Page suggests that
> jujud install juju-mongodb when the package is available, then
> fallback to mongodb-server. This allows us to backport jujuj-mongodb
> in the future.
>
> Fixing this issue may be an opportunity to address bug 1240667. As I
> understand it, that bug wants the rules to change when selecting
> mongodb-server to ensure the version comes from the cloud-archive
> (because the cloud-archive should have a lower priority)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1271937/+subscriptions
>

[Tim Penhey (thumper)]

There was a specific request from sabdfl that the package be called juju-db not juju-mongodb.

Is anyone working on this?