Call for Feedback: LXD local provider

[Nate Finch]

In case you haven't heard of it, the lxd provider basically replaces the
old local provider, running nodes as containers using lxd on the local
machine.
There's a few differences from the the old local provider:

   1. Bootstrap will be a little bit slower on lxd.
      - This is because the local provider didn't create a container for
      the bootstrap node, it used your local machine as the bootstrap node.
      2. The lxd provider doesn't dump junk all over your local machine,
   because it puts the bootstrap node in a container
      - This makes it a lot more robust, and means you never have to worry
      about your lxd environment munging anything on your machine (or
vice versa)
   3. The local provider required that you install a ppa that installed a
   special version of mongo on your machine.
      - The lxd provider does not require this because of #2.
      4. The local provider required sudo credentials at bootstrap because
   of #2.
      - the lxd provider does not require sudo
   5. The local provider was special in a lot of terrible ways.
      - The lxd provider is considerably less special, and in general just
      works like any other provider, which means fewer WTF moments.  Treat it
      basically like you would any other remote provider.

There may be some benefits I'm forgetting, but figured I'd put these out
there.

On Thu, Jan 7, 2016 at 1:33 PM Adam Israel <adam.israel at canonical.com>
wrote:

> This sounds amazing. I’ve been looking forward to this for a while, to see
> how we can optimize the developer workflow under Vagrant. I’ll get a VM
> spun up and see how it looks!
>
> Adam Israel - Software Engineer
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> > On Jan 7, 2016, at 12:48 PM, Jorge O. Castro <jorge at ubuntu.com> wrote:
> >
> > Hi everyone,
> >
> > Katherine walked me through using the new LXD provider in the Juju
> > Alpha: https://linuxcontainers.org/lxd/
> >
> > The one caveat right now is that you need to be on wily or xenial as
> your host.
> >
> > We are collecting feedback here along with the current working
> > instructions:
> https://docs.google.com/document/d/1lbh3ZkkSdBOGRadF_6FWrijbOhH4Vf2f7alrZFr8pz0/edit?usp=sharing
> >
> > Here are my initial results:
> >
> > - This is really, really fast.
> > - I was able to `juju deploy bundle/realtime-syslog-analytics`. Since
> > Juju now natively also supports bundles that's one less thing I needed
> > to worry about. It all just worked.
> >
> > This got me a working spark stack with 9 containers (+1 for the state
> > server) in about 10 minutes on my Thinkpad X230. And since the bundle
> > has proper status it was all just a really nice experience from both a
> > performance and observability standpoint.
> >
> > If you are developing charms then I think you should really
> > investigate making a xenial/wily machine with ppa:juju/devel part of
> > your workflow as soon as you can, I cannot overstate what an
> > improvement this is over the older lxc local provider.
> >
> > Note that the bundle I happened to pick does do a bunch of remote
> > fetching, so I am interested in seeing how deploys work for you
> > speed-wise with this vs. the old local provider. Feedback and bug
> > reports gladly welcome!
> >
> > --
> > Jorge Castro
> > Canonical Ltd.
> > http://jujucharms.com/ - The fastest way to model your service
> >
> > --
> > Juju mailing list
> > Juju at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160107/30a7f500/attachment.html>