[RFE] run diff-bundle against two exported bundles

[Andrea Ieri]

It would be useful to be able to diff bundles even in the absence of a deployed model. Example:

juju diff-bundle ./mybundle_1.yaml ./mybundle_2.yaml

This would allow "offline" comparisons of sites that are not reachable or don't exist anymore, or make it possible to try alternative juju client versions without having to touch production sites at all (e.g. I might want to use some shiny new unreleased formatting option from the edge channel but not want to risk side-effects).

[Richard Harding (rharding)]

Is this worthwhile over just a diff tool though? Is there something that bundle-diff is doing logically that's particularly helpful/useful?

[Andrea Ieri (aieri)]

I do agree that many cases can already be handled by doing simple text comparisons, but I still think this would be worthwhile because whereas a diff tool can only compare the syntax of two yaml files, only juju can compare semantics.

Some useful benefits of diff-bundle, off the top of my head:
* ordering doesn't matter
* yaml anchors
* file includes

Besides, if we determined that running vimdiff or meld on bundle files is already enough, why have `juju diff-bundle` in the first place? After all, any model can be exported to a yaml file... ;)

[John A Meinel (jameinel)]

I'd also say the format of the diff output is going to be different. So if
you are used to looking at the output you'd prefer to see it in the same
way.

I don't know that it is high priority but it does seem useful.

John
=:->

On Tue, Sep 3, 2019, 05:15 Andrea Ieri <email address hidden> wrote:

> I do agree that many cases can already be handled by doing simple text
> comparisons, but I still think this would be worthwhile because whereas
> a diff tool can only compare the syntax of two yaml files, only juju can
> compare semantics.
>
> Some useful benefits of diff-bundle, off the top of my head:
> * ordering doesn't matter
> * yaml anchors
> * file includes
>
> Besides, if we determined that running vimdiff or meld on bundle files
> is already enough, why have `juju diff-bundle` in the first place? After
> all, any model can be exported to a yaml file... ;)
>
> ** Changed in: juju
> Status: Incomplete => New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1842358
>
> Title:
> [RFE] run diff-bundle against two exported bundles
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1842358/+subscriptions
>

[Paul Goins (vultaire)]

Here's another idea for this: diffing bundles with overlays against other bundles with overlays.

This is something that I see when we're dealing with reviewing bundles from Field for BootStack clouds. I may have cloud #1, which BootStack has accepted management of, which was deployed via a bundle plus e.g. 3 overlays. Then I may have proposed cloud #2, which BootStack is reviewing bundles for, which is comprised of a bundle plus overlays as well - maybe 4 overlays in this case because things were refactored or something similar. It'd be good to compare the combination of the bundle and overlays from cloud #1 versus the same combination for cloud #2 to identify intended and unintended deltas.

Presently the closest we can get with Juju's tooling is to compare the pre-handover cloud #1 bundles versus the live cloud #1, and then the live cloud #1 against the proposed cloud #2 bundles.