Re: Consuming MongoDB from a Snap

[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 workloads on the controller, as we
> could use migration.
There's also https://bugs.launchpad.net/snapd/+bug/1664163 which we
found quite annoying with trying to use snaps with charms.  Basically,
there's no way to do lock-step upgrades (esp relevant for no-downtime
and HA deployments of various services).
Cheers,
Danilo
> > > 2. Does snapd work inside LXD containers?

> > Although it's rarely done, it's possible to set up a Juju HA cluster where 
> > some nodes are running inside LXD containers so this is something we'd need 
> > to consider.
> > It would suck if we couldn't test using the lxd provider, though.
> > > From xenial onwards, snapd does indeed work inside LXD containers. I 
> > > followed Stephane's instructions using a xenial container and 
> > > successfully installed a number of non-trivial, working snaps including 
> > > Gustavo's mongo32 snap.

> >   https://stgraber.org/2016/12/07/running-snaps-in-lxd-containers/

> > There is of course more testing to be done but it seems like having Juju's 
> > MongoDB in a snap is certainly doable.

> > - Menno

> > 
> > --
> > 
> > Juju-dev mailing list
> > 
Juju-dev@lists.ubuntu.com
> > 
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> > 


> -- 
> Juju-dev mailing list
> 
Juju-dev@lists.ubuntu.com
> 
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju-dev> 
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Big memory usage improvements

[Danilo Šegan]

Indeed, this is amazing stuff: good job, it's great to see so
significant improvements!
I can't help but wonder about the bootstrap time: it goes up by 75s
(from 114s to 189s, or ~66% increase)? Do you perhaps have multiple
runs comparing just the bootstrap times to ensure it's related more to
the environment state (hardware, network, load) than changes in the
code? Is there any explanation for the difference in the number of
deployments done and models created in roughly the same time (46/946 vs
52/1092, 13/15% decrease)?
It might still be a trade-off worth accepting, and even if it'd be even
better with no trade-offs, it's fine as long as we know about it and
make sure that we evaluate the value/cost proposition for each case.
Cheers,
Danilo
У чет, 13. 10 2016. у 09:39 +1300, Menno Smits пише:
> Christian (babbageclunk) has been busy fixing various memory leaks in
> the Juju controllers and has made some significant improvements.
> Chris (veebers) has been tracking resource usage for a long running
> test which adds and removes a bunch of models and he noticed the
> difference.
> 
> Take a look at the memory usage graphs here:
> 
> Before: http://people.canonical.com/~leecj2/perfscalemem/
> After: http://people.canonical.com/~leecj2/perfscalemem2/
> 
> Interestingly the MongoDB memory usage profile is quite different as
> well. I'm not sure if this is due to Christian's improvements or
> something else.
> 
> There's possibly still some more small leaks somewhere but this is
> fantastic regardless. Thanks to Christian for tackling this and Chris
> for tracking the numbers.
> 
> - Menno
> 
> 
> -- 
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l
> istinfo/juju-dev-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev