juju export-bundle fails to show that applications are on the same lxd machine

[Bas de Bruijne]

If you deploy a bundle where two applications are on the same lxd machine:

---------------------------------------
$ cat bundle.yaml
  designate-bind:
...
    to:
    - memcached/0
    - memcached/1
...
  memcached:
...
    to:
    - lxd:0
    - lxd:1
---------------------------------------

Juju export-bundle fails to show that they are on the same lxd machine:
---------------------------------------
$ juju export-bundle
  designate-bind:
...
    to:
    - lxd:0
    - lxd:1
...
  memcached:
...
    to:
    - lxd:0
    - lxd:1
---------------------------------------

The exported bundle only shows that designate-bind and memcached are both lxd containers on 0 and 1, not that they are on the same lxd container. Since designate-bind and memcached share subordinates in the original bundle, deploying the exported bundle would result in a failing deployment.

The desired result would be:
---------------------------------------
$ juju export-bundle
  designate-bind:
...
    to:
    - memcached/0
    - memcached/1
...
  memcached:
...
    to:
    - lxd:0
    - lxd:1
---------------------------------------

[Heather Lanigan (hmlanigan)]

Juju has no concept of a bundle once it is deployed. The contents are saved in juju as individual charms, applications relations etc. Therefore exporting a bundle including specific units which should be co-located is not feasible.

However an exported bundle should produce the same results as the bundle used to deploy. Can you please provide the full bundle used to deploy?

[Bas de Bruijne (basdbruijne)]

This is the full bundle we use: https://oil-jenkins.canonical.com/artifacts/7335ce09-a5f9-420b-9521-e2613cd2a488/generated/generated/openstack/bundle.yaml

[John A Meinel (jameinel)]

I think Bas's comment is pointing towards the fact that we support bundle
syntax that lets you say "place units of this aligned with an application"
but we don't save that information, and only record what machine it was
allocated to.
As a concrete example (without containers):
$ cat ./bundle.yaml
applications:
  source:
      charm: ./dummy-source
      series: bionic
      scale: 2
  sink:
      charm: ./dummy-sink
      scale: 2
      series: bionic
      to:
          - source/0
          - source/1

When I deploy that you get:
...
- add unit sink/2 to new machine 7 to satisfy [source/0]
- add unit sink/3 to new machine 8 to satisfy [source/1]

However, if you then export it back you just get:
$ juju export-bundle
series: focal
applications:
  sink:
    charm: local:dummy-sink-1
    series: bionic
    num_units: 2
    to:
    - "7"
    - "8"
  source:
    charm: local:dummy-source-0
    series: bionic
    num_units: 2
    to:
    - "7"
    - "8"
  ubuntu-lite:
    charm: jameinel-ubuntu-lite
    channel: stable
    revision: 9
    num_units: 1
    to:
    - "0"
machines:
  "0":
    constraints: arch=amd64
  "7":
    constraints: arch=amd64
    series: bionic
  "8":
    constraints: arch=amd64
    series: bionic

Note that sink is no longer stated as "place me where source was placed" it
is just that sink is targeting "machine 7" and source is targeted at
"machine 7" as well.

On Thu, Mar 31, 2022 at 11:05 AM Heather Lanigan <email address hidden>
wrote:

> Juju has no concept of a bundle once it is deployed. The contents are
> saved in juju as individual charms, applications relations etc.
> Therefore exporting a bundle including specific units which should be
> co-located is not feasible.
>
> However an exported bundle should produce the same results as the bundle
> used to deploy. Can you please provide the full bundle used to deploy?
>
> ** Changed in: juju
> Status: Triaged => Incomplete
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1967287
>
> Title:
> juju export-bundle fails to show that applications are on the same lxd
> machine
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1967287/+subscriptions
>
>

[Bas de Bruijne (basdbruijne)]

Yes John, that is exactly what I mean.

In your example it is not really a problem, since the sink and source end up on the same machine in both the initial and exported bundle.
However, when the source is an Lxd machine (like memcached in my initial example), the exported bundle still places the sink and source on the same machine, but not on the same container.