Re: Consuming MongoDB from a Snap

2017-08-01 Thread Michael Hudson-Doyle
On 31 July 2017 at 20:24, Mark Shuttleworth wrote: > On 31/07/17 01:34, Michael Hudson-Doyle wrote: > > On 23 June 2017 at 11:47, Menno Smits wrote: > >> We've had some discussion this week about whether Juju could use MongoDB >> from snap instead of a deb. This would make it easier for Juju to

Re: Consuming MongoDB from a Snap

2017-07-31 Thread Mark Shuttleworth
On 31/07/17 01:34, Michael Hudson-Doyle wrote: > On 23 June 2017 at 11:47, Menno Smits > wrote: > > We've had some discussion this week about whether Juju could use > MongoDB from snap instead of a deb. This would make it easier for > Juju to stay up t

Re: Consuming MongoDB from a Snap

2017-07-30 Thread Michael Hudson-Doyle
On 23 June 2017 at 11:47, Menno Smits wrote: > We've had some discussion this week about whether Juju could use MongoDB > from snap instead of a deb. This would make it easier for Juju to stay up > to date with the latest MongoDB releases, avoiding the involved process > getting each update into

Re: Consuming MongoDB from a Snap

2017-07-26 Thread John Meinel
I just wanted to note that some of the reason for 128GB was because 2.0 and 2.1 did leak memory over time. And if you have a leak you will always eventually run out. In 2.2 we've fixed all the ones we've found so far and we're actively doing some performance measuring to give better guidelines. (If

Re: Consuming MongoDB from a Snap

2017-07-26 Thread Felipe Reyes
On Wed, 26 Jul 2017 15:58:30 +0100 Mark Shuttleworth wrote: > On 26/07/17 15:51, Felipe Reyes wrote: > > Some users run the controller in fairly big bare metal machines > > (e.g. 128G of RAM, I've seen even bigger controllers) and it won't > > be easy for them to have an extra machine to setup a

Re: Consuming MongoDB from a Snap

2017-07-26 Thread Felipe Reyes
On Fri, 23 Jun 2017 00:09:14 + Andrew Wilkins wrote: > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits > wrote: > > > We've had some discussion this week about whether Juju could use > > MongoDB from snap instead of a deb. This would make it easier for > > Juju to stay up to date with the lates

Re: Consuming MongoDB from a Snap

2017-07-26 Thread Mark Shuttleworth
On 26/07/17 15:51, Felipe Reyes wrote: > Some users run the controller in fairly big bare metal machines (e.g. > 128G of RAM, I've seen even bigger controllers) and it won't be easy for > them to have an extra machine to setup a new controller and run model > migration, if their controller is HA th

Re: Consuming MongoDB from a Snap

2017-06-28 Thread Menno Smits
Thanks for the detailed feedback Dmitrii. We will go through the areas you've highlighted before making any decisions on this. At any rate, this is unlikely to happen soon. On 27 June 2017 at 08:15, Dmitrii Shcherbakov < dmitrii.shcherba...@canonical.com> wrote: > Hi everybody, > > Thanks for hig

Re: Consuming MongoDB from a Snap

2017-06-26 Thread Dmitrii Shcherbakov
Hi everybody, Thanks for highlighting this in a public thread. Before switching to snaps, please consider mongodb lifetime as snapd does not give you any strict lifetime guarantees as of now: 1. it will try to stop a service on update; 2. will send SIGTERM if that timed out; 3. if processes in t

Re: Consuming MongoDB from a Snap

2017-06-24 Thread Nicholas Skaggs
On Fri, Jun 23, 2017 at 10:36 AM, Menno Smits wrote: > > > On 23 June 2017 at 12:09, Andrew Wilkins > wrote: > >> >>> *1. Does snapd work on all architectures that Juju supports?* >>> >>> The answer appears to be "yes with some caveats". For xenial onwards >>> there are snapd packages for all th

Re: Consuming MongoDB from a Snap

2017-06-23 Thread Danilo Šegan
У пет, 23. 06 2017. у 09:00 +0200, Danilo Šegan пише: > > ...there's no way to do lock-step upgrades... That's, of course, too strong. What I meant was that there is no way to do lock-step upgrades while using the default daemon specifications: you can always decide to do the systemd control of se

Re: Consuming MongoDB from a Snap

2017-06-23 Thread Danilo Šegan
У пет, 23. 06 2017. у 00:09 +, Andrew Wilkins пише: > > One issue would be upgrades: we would either have to continue > supporting both snaps and debs for mongodb, or we would have to > disallow upgrading from a system that doesn't support snaps. That > would OK as long as there are no workloa

Re: Consuming MongoDB from a Snap

2017-06-22 Thread Stuart Bishop
On 23 June 2017 at 06:47, Menno Smits wrote: > There is of course more testing to be done but it seems like having Juju's > MongoDB in a snap is certainly doable. The snap story for offline or limited-network deployments needs to be worked out. In particular, there are no methods for a local cac

Re: Consuming MongoDB from a Snap

2017-06-22 Thread Menno Smits
On 23 June 2017 at 12:25, Michael Hudson-Doyle wrote: > >>> The answer appears to be "yes with some caveats". For xenial onwards >>> there are snapd packages for all the architectures the Juju team cares >>> about. >>> >> >> Ah, I thought the question was rather whether or not the mongo snap >> e

Re: Consuming MongoDB from a Snap

2017-06-22 Thread Menno Smits
On 23 June 2017 at 12:09, Andrew Wilkins wrote: > >> *1. Does snapd work on all architectures that Juju supports?* >> >> The answer appears to be "yes with some caveats". For xenial onwards >> there are snapd packages for all the architectures the Juju team cares >> about. >> > > Ah, I thought th

Re: Consuming MongoDB from a Snap

2017-06-22 Thread Michael Hudson-Doyle
On 23 June 2017 at 12:09, Andrew Wilkins wrote: > On Fri, Jun 23, 2017 at 7:47 AM Menno Smits > wrote: > >> We've had some discussion this week about whether Juju could use MongoDB >> from snap instead of a deb. This would make it easier for Juju to stay up >> to date with the latest MongoDB rel

Re: Consuming MongoDB from a Snap

2017-06-22 Thread Andrew Wilkins
On Fri, Jun 23, 2017 at 7:47 AM Menno Smits wrote: > We've had some discussion this week about whether Juju could use MongoDB > from snap instead of a deb. This would make it easier for Juju to stay up > to date with the latest MongoDB releases, avoiding the involved process > getting each update