[FFe] Split out mongodb-server-core

[Nicholas Skaggs]

I am requesting a mongodb-server-core package that provides only mongodb-server-binaries, with no user or services management. The package should remain in universe, and be supported accordingly.

Rationale:
Juju is migrating to mongodb 3.4 for bionic, and would like to phase out the usage of juju-mongodb packages. The proposed mongodb-server-core package will meet juju's needs, as well as potentially other users needs within the archive who may have utilized juju-mongodb for it's similar properties.

Lifespan:
Juju is actively working to migrate to a more tightly coupled distribution for mongodb (as with juju agents, simplestreams) that would better serve the fast paced nature of the project. Therefore the juju team anticipates no longer depending on this package post-bionic.

Logs:
There is no upstream changelog, as the version hasn't changed.

https://launchpadlibrarian.net/357300754/buildlog_ubuntu-bionic-amd64.mongodb_1%3A3.4.7-1ubuntu3~ppa2_BUILDING.txt.gz

Package:
The proposed package has already been built thanks to Robie Basak, and can be seen in his ppa: ppa:racb/experimental. Robie has also graciously volunteered to upload this package to fufill this FFe.

Testing:
The juju team has done initial validation to ensure this meets our needs. This included running our test suite utilizing the packaged mongodb from Robie's ppa.

[Stéphane Graber (stgraber)]

I don't mind the approach as it just sounds like splitting existing binary packages in universe.

If I understand this correct, it's not actually causing the addition or removal of a feature in Ubuntu, it's effectively purely cosmetic so I'm not sure an FFe was even needed for this in the first place.

Anyway, if a binary package split is all it is and someone is going to be dealing with maintenance of this delta going forward, I'm fine with it.

[Nicholas Skaggs (nskaggs)]

Thanks. You are correct. This is just playing with packaging; the source is unchanged. I was thinking the same about not needing an FFe, but I filed one anyway. If nothing else, it can provide clarity for anyone who may have wondered why the split occurred.

[Dimitri John Ledkov (xnox)]

Do we need to continue shipping juju-mongo-tools3.2 in bionic?

Do we need to continue shipping juju-mongodb3.2 in bionic?

Are you aware that juju-mongodb3.2, has JS engine turned off, and is thus more secure than the monogdb source, which has JS engine compiled in - and thus has all the security vulnerabilities of a full web-browser more or less?

Please note the JS engine in src:mongodb does not receive security vulnerabilities patches.

Don't you instead want a mongodb 3.4, compiled in a similar fashion as the juju-mongodb3.2 package (wihtout js), avoiding forking the current packaging of src:mongodb?

With the intention that juju-mongodb3.4 is short-lived, until the daemon moves off using in-archive version.

[Dimitri John Ledkov (xnox)]

I'm afraid of mongodb JS engine security vulnerabilities, impacting juju security, even during the interim period whilst it is still in use.

[Robie Basak (racb)]

> Do we need to continue shipping juju-mongo-tools3.2 in bionic?

> Do we need to continue shipping juju-mongodb3.2 in bionic?

These can presumably be removed, but let's wait for an upstream ack after this change to src:mongodb has landed.

About the rest, what Juju upstream chooses to do has nothing to do with Ubuntu-the-distribution. The request for a core binary package stands on its own as it follows a similar pattern to what is already done in MySQL and MariaDB. It's not Juju-specific either - it's quite a reasonable general request.

[Dimitri John Ledkov (xnox)]

the packaging splits are indeed good for the distro, in general.

but I also want to make sure Ubuntu is providing the best solutions for Juju upstream, too. As one of the users of our platform.

Before Feature Freeze, I was trying to get mongodb 3.6 building, but ran out of disk-space on official builders to successfully build it. Thus one more question - why move to 3.4, when 3.6 is the current stable series? Maybe it makes sense to skip 3.4 altogether, and go straight for 3.6?

Is juju trying to use mongodb 3.4, simply because that is what is stale and available in bionic universe?

[Robie Basak (racb)]

On Wed, Mar 21, 2018 at 12:21:12AM -0000, Dimitri John Ledkov wrote:
> Before Feature Freeze, I was trying to get mongodb 3.6 building, but ran
> out of disk-space on official builders to successfully build it. Thus
> one more question - why move to 3.4, when 3.6 is the current stable
> series? Maybe it makes sense to skip 3.4 altogether, and go straight for
> 3.6?
>
> Is juju trying to use mongodb 3.4, simply because that is what is stale
> and available in bionic universe?

Debian is on 3.4 in experimental and I'm not aware of any 3.6 packaging
that is ready. So pushing ahead to 3.6 and maintaining that for five
years would be a significant amount of increased work and commitment.
It's also well past feature freeze now. If your team wants to take that
on, feel free to go ahead but please make sure to coordinate with the
release team, Juju upstream and any other stakeholders as appropriate.

[John A Meinel (jameinel)]

Likely we should remove juju-mongodb3.2 from bionic once we actually have an alternative and can trust that it actually works. It is my understanding that 3.2 FTBFS and nobody was willing to maintain it.
Given the option, yes we would prefer a 3.4 without the JS engine. My understanding is that nobody was willing to build the package and the person on our team that had done it in the past (mwh) has left the team and no longer has time to maintain it.

The only package that anyone has put the effort into building was Mongolian 3.4.7 synced from debian, and so we asked to split it.

As for 3.6 vs 3.4, porting to 3.4 was not trivial though it wasn't a lot of changes. I would expect another amount of work to support 3.6. We'd probably be willing to do that work, but only if we could actually get something.

AIUI one of the primary reasons JS was removed was actually because of non amd64 arch compiling issues. So it may be that a 3.6 w/o JS would be easier to compile/maintain.
But we don't have the experience in-Juju (nor a MOTU). So 3.4 synced from debian seemed the best we could do.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mongodb - 1:3.4.7-1ubuntu4

---------------
mongodb (1:3.4.7-1ubuntu4) bionic; urgency=medium

  * d/p/disable-broken-ppc64el-altivec: disable buggy AltiVec optimisations on
    ppc64el for now to fix FTBFS until upstream has a proper fix (LP:
    #1758116). This may result in a performance regression on ppc64el only,
    which is tracked at LP 1758118.

 -- Robie Basak <email address hidden> Thu, 22 Mar 2018 12:49:32 +0000