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 stay up
>> to date with the latest MongoDB releases, avoiding the involved process
>> getting each update into Ubuntu's update repository, as well as giving us
>> all the other advantages of snaps.
>>
>
> Given that juju-mongodb 3.2.15 has been sitting in the xenial review queue
> for three weeks and now 3.2.16 has come out...
>
> It is clear that the SRU process is not really a good fit for getting new
> versions of mongodb to juju controllers in the wild. What else could work?
> A PPA perhaps, but that has some of the same offline story problems as
> snaps, you'd need to include the PPA in whichever archive mirror the
> controller nodes are configured to use. You could use a stream-based
> approach similar to how jujud is installed, I guess? Probably best to ship
> a deb or a snap in the stream though, you don't want to be re-implementing
> the upgrade support and process management stuff yourself if you don't have
> too. (Shipping a deb you'd need to so some worrying about how easy it is to
> build per-series debs or build a mongodb that is statically linked enough
> to work across different series -- don't really know how much work either
> of those would entail).
>
>
> At some level it's weird to express something as a deb which only exists
> to be used by one thing - Juju. The deb dependency system is really good
> for things that end up being widely useful, but not great for something
> like juju-mongodb. It has always felt like an awkwardness that would be
> better managed internally to the jujud package. There are attendant costs -
> security updates etc. But we already have duplication in that we have a
> whole copy of mongodb. Where that copy lives is not material, it should
> therefor live where it is most convenient for the people who use it, which
> is jujud.
>

I chatted to Menno about this on IRC today, and I think the conclusion we
came to was that having juju-mongodb in a deb was OK (it handles upgrades
and running the service and so on fine) but shipping it via the archive is
not really -- building mongodb into a deb and distributing that via streams
alongside jujud would be better.

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

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 to date with the latest MongoDB releases, avoiding
> the involved process getting each update into Ubuntu's update
> repository, as well as giving us all the other advantages of snaps.
>
>  
> Given that juju-mongodb 3.2.15 has been sitting in the xenial review
> queue for three weeks and now 3.2.16 has come out...
>
> It is clear that the SRU process is not really a good fit for getting
> new versions of mongodb to juju controllers in the wild. What else
> could work? A PPA perhaps, but that has some of the same offline story
> problems as snaps, you'd need to include the PPA in whichever archive
> mirror the controller nodes are configured to use. You could use a
> stream-based approach similar to how jujud is installed, I guess?
> Probably best to ship a deb or a snap in the stream though, you don't
> want to be re-implementing the upgrade support and process management
> stuff yourself if you don't have too. (Shipping a deb you'd need to so
> some worrying about how easy it is to build per-series debs or build a
> mongodb that is statically linked enough to work across different
> series -- don't really know how much work either of those would entail).

At some level it's weird to express something as a deb which only exists
to be used by one thing - Juju. The deb dependency system is really good
for things that end up being widely useful, but not great for something
like juju-mongodb. It has always felt like an awkwardness that would be
better managed internally to the jujud package. There are attendant
costs - security updates etc. But we already have duplication in that we
have a whole copy of mongodb. Where that copy lives is not material, it
should therefor live where it is most convenient for the people who use
it, which is jujud.

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

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 Ubuntu's update repository, as well as giving us
> all the other advantages of snaps.
>

Given that juju-mongodb 3.2.15 has been sitting in the xenial review queue
for three weeks and now 3.2.16 has come out...

It is clear that the SRU process is not really a good fit for getting new
versions of mongodb to juju controllers in the wild. What else could work?
A PPA perhaps, but that has some of the same offline story problems as
snaps, you'd need to include the PPA in whichever archive mirror the
controller nodes are configured to use. You could use a stream-based
approach similar to how jujud is installed, I guess? Probably best to ship
a deb or a snap in the stream though, you don't want to be re-implementing
the upgrade support and process management stuff yourself if you don't have
too. (Shipping a deb you'd need to so some worrying about how easy it is to
build per-series debs or build a mongodb that is statically linked enough
to work across different series -- don't really know how much work either
of those would entail).

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

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 you are running X machines Y units you need a machine with A cores and
B memory.)
There are a lot of different ways to stress Juju (lots of small models, one
giant model, etc) and many performance numbers are soft (command X gets
slower, but doesn't fail, at what point do we consider it unusable).

All this to say, we've run ~2000 units against 16GB of memory. There really
shouldnt be a need to go to 128+ in the future. Current results show us to
be more CPU constrained (at least during deploy, etc) on normal RAM vs CPU
ratios.

John
=:->

On Jul 26, 2017 16:51, "Felipe Reyes"  wrote:

> 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 latest MongoDB releases, avoiding
> > > the involved process getting each update into Ubuntu's update
> > > repository, as well as giving us all the other advantages of snaps.
> > >
> > > Two concerns were raised in this week's tech board meeting.
> > >
> > > *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 the question was rather whether or not the mongo snap
> > existed for all of those architectures. I don't think it does. IIANM,
> > the snap comes from
> > https://github.com/niemeyer/snaps/blob/master/mongodb/
> mongo32/snapcraft.yaml,
> > which (if you look at the "mongodb" part, appears to only exist for
> > x86_64). So we would need to do some work on that first.
> >
> >
> > >https://packages.ubuntu.com/xenial/snapd
> > >
> > > For trusty only amd64, armhf and i386 appear to be supported.
> > >
> > >https://packages.ubuntu.com/trusty-updates/snapd
> > >
> > > This is probably ok. I think it's probably fine to start saying
> > > that new Juju controllers, on some architectures at least, need to
> > > be based on xenial or later.
> > >
> >
> > Since the controller machine isn't designed for workloads, it seems
> > fine to me to restrict them to latest LTS.
> >
> > 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.
>
> 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 then 3 spare machines are
> needed, this is hard to justify.
>
> --
> Felipe Reyes
> Software Sustaining Engineer @ Canonical
> # Launchpad: ~freyes | IRC: freyes
>
> --
> 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: 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 new controller
> > and run model migration, if their controller is HA then 3 spare
> > machines are needed, this is hard to justify.  
> 
> Could LXD solve that problem?
> 
> Seems like having A/B containers in each of those machines would be
> fine. The total amount of work isn't growing, it's just shifting from
> one codebase to the next.
> 
> So, the three machines each get two containers, the Juju controller is
> spread across three A controllers, the new one goes into the B
> controllers, and migration essentially takes place on the same
> hardware.

Sounds like a good option, specially since this may open the door to
have faster rollbacks, something we achieve today using VM snapshots
and/or "juju backups".

We just need to be careful to not assume the machine will have enough
resources to have both containers (jujud and mongod in them
specifically) running at the same time.

-- 
Felipe Reyes
Software Sustaining Engineer @ Canonical
# Launchpad: ~freyes | IRC: freyes

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

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 latest MongoDB releases, avoiding
> > the involved process getting each update into Ubuntu's update
> > repository, as well as giving us all the other advantages of snaps.
> >
> > Two concerns were raised in this week's tech board meeting.
> >
> > *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 the question was rather whether or not the mongo snap
> existed for all of those architectures. I don't think it does. IIANM,
> the snap comes from
> https://github.com/niemeyer/snaps/blob/master/mongodb/mongo32/snapcraft.yaml,
> which (if you look at the "mongodb" part, appears to only exist for
> x86_64). So we would need to do some work on that first.
> 
> 
> >https://packages.ubuntu.com/xenial/snapd
> >
> > For trusty only amd64, armhf and i386 appear to be supported.
> >
> >https://packages.ubuntu.com/trusty-updates/snapd
> >
> > This is probably ok. I think it's probably fine to start saying
> > that new Juju controllers, on some architectures at least, need to
> > be based on xenial or later.
> >  
> 
> Since the controller machine isn't designed for workloads, it seems
> fine to me to restrict them to latest LTS.
> 
> 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.

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 then 3 spare machines are
needed, this is hard to justify.

-- 
Felipe Reyes
Software Sustaining Engineer @ Canonical
# Launchpad: ~freyes | IRC: freyes

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

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 then 3 spare machines are
> needed, this is hard to justify.

Could LXD solve that problem?

Seems like having A/B containers in each of those machines would be
fine. The total amount of work isn't growing, it's just shifting from
one codebase to the next.

So, the three machines each get two containers, the Juju controller is
spread across three A controllers, the new one goes into the B
controllers, and migration essentially takes place on the same hardware.

Mark

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

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 the unit's cgroup are still alive after a SIGTERM
timeout it will SIGKILL all of them.

Now, it might be a good idea from the first sight to keep stuff
updated, but I do not want to be in a situation where I have to
explain to a customer that his model is corrupted due to an update
that happened during his 100-node deployment or an update process
where there have been a high volume of traffic preventing the mongodb
service from stopping.

Even if a database could be recovered after a forced crash, filing
charm bugs and restoring a correct state after some lost events would
be a nightmare.

It is a question of update safety which is quite generic.

Please take a look at the forum thread below and an e-mail thread. I
had exactly the same question for libvirt and QEMU. This is valid for
any critical services such as LXD, docker, openvswitch etc.

https://forum.snapcraft.io/t/process-lifecycle-on-snap-refresh/140
https://lists.ubuntu.com/archives/snapcraft/2017-March/003674.html

https://bugs.launchpad.net/snappy/+bug/1632508

Just follow the code path below and you will see it:

https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapstate.go#L582-L601

https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapstate.go#L113-L123

https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/snapmgr.go#L324-L326

https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/handlers.go#L770-L791

https://github.com/snapcore/snapd/blob/release/2.26/overlord/snapstate/backend/link.go#L81-L83

systemctl stop -> SIGTERM -> SIGKILL
https://github.com/snapcore/snapd/blob/release/2.26/wrappers/services.go#L107-L127

The actual implementation which just calls systemd:
https://github.com/snapcore/snapd/blob/release/2.26/systemd/systemd.go#L279-L323

Or, in a single paste but for an earlier version
https://paste.ubuntu.com/24262077/



Have you guys considered that? I understand Juju client updates but we
should really be careful about mongodb updates.

This is a critical point to consider - please don't ignore it.

---

LXD and snapd:

squashfuse must be installed in a container in order for this to work.
Unless you have that, you cannot mount a squashfs file system as there
is no CAP_SYS_ADMIN for unprivileged containers:

http://man7.org/linux/man-pages/man7/capabilities.7.html

"CAP_SYS_ADMIN
...
Perform a range of system administration operations including: ...
mount(2), umount(2),..."

https://lwn.net/Articles/486306/

snapd does not depend on squashfuse currently:
https://packages.ubuntu.com/xenial-updates/snapd

https://packages.ubuntu.com/search?keywords=squashfuse

---

Offline upgrades:

A CDN is used to distribute snap packages, hence, this requires a more
careful handling for offline environments.

See my answer here for hostnames I have found to be used:
https://lists.ubuntu.com/archives/juju/2017-March/008795.html

Technically, a snap store is a web application giving certain files
away by virtue of a REST API.
https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex

Somebody even tried creating their own bare-bones snap store but this
story is not production-ready yet in my view.
https://github.com/noise/snapstore

Hence, for the field team to use it, we need to have a good story for
that - it would make our live much harder if there wasn't any verified
solution for this.

---

I am open to any feedback regarding auto-updates and offline updates
as this will directly impact what I do.

Thanks in advance.

On 23 Jun 2017 09:08, "Danilo Šegan"  wrote:

У пет, 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
services yourself.

Cheers,
Danilo

--
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: 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 the architectures the Juju team cares
>>> about.
>>>
>>
>> Ah, I thought the question was rather whether or not the mongo snap
>> existed for all of those architectures. I don't think it does. IIANM, the
>> snap comes from https://github.com/niemeyer/snaps/blob/master/mongodb/
>> mongo32/snapcraft.yaml, which (if you look at the "mongodb" part,
>> appears to only exist for x86_64). So we would need to do some work on that
>> first.
>>
>
> ​I imagine we would have a custom MongoDB snap for Juju rather than using
> this one as is. We want direct control over the snap. The niemeyer snap
> would probably be a good starting point though.
>
Long term, I think it would be interesting to switch the unit payload over
to a snap. One snap would get you the agent, and everything you need to run
it. Barring the issues with snaps, this would make the entire story quite
clean. I know we spoken about this in the past, but I think it makes sense
to keep in mind if you wish to migrate. Juju should bundle everything into
a juju server snap. On the client / bootstrap side, centos, windows, and
mac support is still something to keep in mind.

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

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 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: 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
>> existed for all of those architectures. I don't think it does. IIANM, the
>> snap comes from https://github.com/niemeyer/snaps/blob/master/mongodb/
>> mongo32/snapcraft.yaml, which (if you look at the "mongodb" part,
>> appears to only exist for x86_64). So we would need to do some work on that
>> first.
>>
>
> Mongo 3.2 upstream doesn't support s390x. 3.4 does though, so I don't see
> any immediate reason why a snap of 3.4 couldn't support all arches we care
> about.
>
> I was asking about snaps in the context of moving to 3.4, really.
>

​It makes sense to ​do the switch to a MongoDB snap as part of the move to
MongoDB 3.4.

   https://packages.ubuntu.com/xenial/snapd
>>>
>>> For trusty only amd64, armhf and i386 appear to be supported.
>>>
>>>https://packages.ubuntu.com/trusty-updates/snapd
>>>
>>> This is probably ok. I think it's probably fine to start saying that new
>>> Juju controllers, on some architectures at least, need to be based on
>>> xenial or later.
>>>
>>
>> Since the controller machine isn't designed for workloads, it seems fine
>> to me to restrict them to latest LTS.
>>
>
> Eh well, there is no juju-mongodb3.2 package for trusty at all is there?
>

True. There's a juju-mongodb for trusty but is has 2.4.9 so a lack of snapd
support for some arches on trusty is a moot point.

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

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 the question was rather whether or not the mongo snap
> existed for all of those architectures. I don't think it does. IIANM, the
> snap comes from https://github.com/niemeyer/snaps/blob/master/
> mongodb/mongo32/snapcraft.yaml, which (if you look at the "mongodb" part,
> appears to only exist for x86_64). So we would need to do some work on that
> first.
>

​I imagine we would have a custom MongoDB snap for Juju rather than using
this one as is. We want direct control over the snap. The niemeyer snap
would probably be a good starting point though.



>
>>https://packages.ubuntu.com/trusty-updates/snapd
>>
>> This is probably ok. I think it's probably fine to start saying that new
>> Juju controllers, on some architectures at least, need to be based on
>> xenial or later.
>>
>
> Since the controller machine isn't designed for workloads, it seems fine
> to me to restrict them to latest LTS.
>
> 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.
>

This would certainly be a good case to use migrations.​

*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.
>

/me slaps forehead for forgetting the more obvious use case.​

At any rate, snapd in LXD containers does seem to work from xenial onwards.

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

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 releases, avoiding the involved process
>> getting each update into Ubuntu's update repository, as well as giving us
>> all the other advantages of snaps.
>>
>> Two concerns were raised in this week's tech board meeting.
>>
>> *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 the question was rather whether or not the mongo snap
> existed for all of those architectures. I don't think it does. IIANM, the
> snap comes from https://github.com/niemeyer/snaps/blob/master/
> mongodb/mongo32/snapcraft.yaml, which (if you look at the "mongodb" part,
> appears to only exist for x86_64). So we would need to do some work on that
> first.
>

Mongo 3.2 upstream doesn't support s390x. 3.4 does though, so I don't see
any immediate reason why a snap of 3.4 couldn't support all arches we care
about.

I was asking about snaps in the context of moving to 3.4, really.

   https://packages.ubuntu.com/xenial/snapd
>>
>> For trusty only amd64, armhf and i386 appear to be supported.
>>
>>https://packages.ubuntu.com/trusty-updates/snapd
>>
>> This is probably ok. I think it's probably fine to start saying that new
>> Juju controllers, on some architectures at least, need to be based on
>> xenial or later.
>>
>
> Since the controller machine isn't designed for workloads, it seems fine
> to me to restrict them to latest LTS.
>

Eh well, there is no juju-mongodb3.2 package for trusty at all is there?

Cheers,
mwh


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.
>
> *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: 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 into Ubuntu's update repository, as well as giving us
> all the other advantages of snaps.
>
> Two concerns were raised in this week's tech board meeting.
>
> *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 the question was rather whether or not the mongo snap existed
for all of those architectures. I don't think it does. IIANM, the snap
comes from
https://github.com/niemeyer/snaps/blob/master/mongodb/mongo32/snapcraft.yaml,
which (if you look at the "mongodb" part, appears to only exist for
x86_64). So we would need to do some work on that first.


>https://packages.ubuntu.com/xenial/snapd
>
> For trusty only amd64, armhf and i386 appear to be supported.
>
>https://packages.ubuntu.com/trusty-updates/snapd
>
> This is probably ok. I think it's probably fine to start saying that new
> Juju controllers, on some architectures at least, need to be based on
> xenial or later.
>

Since the controller machine isn't designed for workloads, it seems fine to
me to restrict them to latest LTS.

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.

*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