1) This was only a problem because I switched from Deb LXD to Snap LXD
which left me with a zfs pool juju-zfs but no LXD storage pool record. This
meant that CreatePool always fails.
2) Juju allows there to be no storage pool, (it just doesn't let you do
special attachments)
3) We were failing because the error you get changes when you're
concurrently calling Create and Get (I don't know if you need multiple
create in parallel)
So the ultimate issue is that the underlying provider was in a bad state.
I would argue that Juju shouldn't really be creating a "juju-zfs" pool
unless the user has asked for special storage. (we don't create ebs volumes
until you want them).
(Juju can't know how you want to use it, so we're just as likely to be
wasting space because you don't use it, or not using enough because you
want something really big)
It is nice to be able to just play with the storage primitives. But it does
feel like the pool shouldn't be allocated during AddModel.
Unless we were using that storage for the container images themselves. But
as I bootstrapped and then saw that juju-zfs was not in use, I don't think
that is the case. (we also create a juju-btrfs which appears to go unused
as well).
The "fix" is to fix my underlying provider (get LXD to either use the
existing pool or delete the pool and have us create it from scratch).
The ultimate fix feels more like asking why we're doing it in the first
place.
John
=:->
On Jan 9, 2018 7:10 AM, "Tim Penhey" <email address hidden> wrote:
> While LXD may indeed have an issue, it is Juju's responsibility to make
> things work even against flakey substrates.
>
> What does Juju need to do to work in this situation?
>
> ** Changed in: juju
> Status: Invalid => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1738614
>
> Title:
> LXD pool already exists
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1738614/+subscriptions
>
Here's my understanding.
1) This was only a problem because I switched from Deb LXD to Snap LXD
which left me with a zfs pool juju-zfs but no LXD storage pool record. This
meant that CreatePool always fails.
2) Juju allows there to be no storage pool, (it just doesn't let you do
special attachments)
3) We were failing because the error you get changes when you're
concurrently calling Create and Get (I don't know if you need multiple
create in parallel)
So the ultimate issue is that the underlying provider was in a bad state.
I would argue that Juju shouldn't really be creating a "juju-zfs" pool
unless the user has asked for special storage. (we don't create ebs volumes
until you want them).
(Juju can't know how you want to use it, so we're just as likely to be
wasting space because you don't use it, or not using enough because you
want something really big)
It is nice to be able to just play with the storage primitives. But it does
feel like the pool shouldn't be allocated during AddModel.
Unless we were using that storage for the container images themselves. But
as I bootstrapped and then saw that juju-zfs was not in use, I don't think
that is the case. (we also create a juju-btrfs which appears to go unused
as well).
The "fix" is to fix my underlying provider (get LXD to either use the
existing pool or delete the pool and have us create it from scratch).
The ultimate fix feels more like asking why we're doing it in the first
place.
John
=:->
On Jan 9, 2018 7:10 AM, "Tim Penhey" <email address hidden> wrote:
> While LXD may indeed have an issue, it is Juju's responsibility to make /bugs.launchpad .net/bugs/ 1738614 /bugs.launchpad .net/juju/ +bug/1738614/ +subscriptions
> things work even against flakey substrates.
>
> What does Juju need to do to work in this situation?
>
> ** Changed in: juju
> Status: Invalid => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> LXD pool already exists
>
> To manage notifications about this bug go to:
> https:/
>