Juju cloud update and fallback precedence

[Nam Nguyen]

# Right now we have the following files:
- https://streams.canonical.com/juju/public-clouds.syaml (1)
- public-clouds.yaml (2)
- fallback-public-cloud.yaml (3)

(1) get's saved into (2) by running `juju update-clouds`

Using juju cloud commands will use (2) and not (3).
If for any cause, (3) gets updated and (1) not yet, one has to delete the file (2) to make (3) work.

In my opinion, it makes sense that (1) and (2) takes precedence over (3).
But there can be cases which can be confusing:

- when we need to update (3) first and test them, we actually need to delete (2) first, else it will not work

- when a customer updates to the newest juju client and did no `juju update-clouds` (2) will be used, not (3). Which can be reasonable but also confusing for them.

I propose to discuss this further in this bug description.

Possible solutions could be:
- some kind of merge
- logging indicating a mismatch between fallback and own cloud
- ?

e.g. of validation wanted https://github.com/juju/juju/pull/10782#pullrequestreview-305960827 hence this description

[Nam Nguyen (nammn)]

This came up as it seems that some people are confused about how the current process works or should work.

Some work regarding streamlining/making it clearer could help.

[Nam Nguyen (nammn)]

https://github.com/juju/juju/pull/10782

[Anastasia (anastasia-macmood)]

Original design catered for the fact that there are 3 ilks of clouds that Juju is involved with - "public" clouds [aws, azure, vsphere, etc], "built-in" clouds [lxd, k8s, etc], "personal" clouds [openstack, maas, etc installations].

To support that distinctly different commands were created: for example, 'update-clouds' and 'update-public-clouds'. This allowed different level of control and flexibility to Juju developers but caused a lot of confusion with the users since the above distinction is not always clear and is kind of irrelevant in the running system. What is relevant is whether the cloud is on the client or on the controller.

So Juju evolved :) And out understanding of user needs and use cases led us to change the way we view clouds and surrounding CRUD. In Paris, we have addressed this and as a result only client vs controller distinction is being made clear in cloud UX. The above update commands will be combined so the disparity between what gets updated and what clouds command sees will be less painful that what you describe.

As for the warnings... Juju does have plenty of warnings in human readable format that advises users to update public clouds when the difference is detected. This is about to be changed since 'update-public-clouds' is going to be deprecated in favor of 'update-cloud'

[Anastasia (anastasia-macmood)]

I am not convinced that this is a Juju bug.

What is (3) fallback-public-clouds.yaml is used for? If it's for publishing new clouds/regions, then it is more of a release tools concern. No user/operator should deal with it or know about it...Only juju developers that release/update canonical knowledge of public clouds... Maybe it is lacking documentation?

(1) public-clouds.yaml from Canonical's streams and (2) public-clouds.yaml from Juju client are used by Juju code and are causing no confusion.

[Ian Booth (wallyworld)]

fallback-public-clouds was intended to allow Juju to work out of the box even if update-public-clouds has not been run. No end user should ever be aware of its existence. The idea was that we'd compile into the juju binary this default cloud info so no matter what, relatively recent public cloud info was available available. End users would be expected to run update-public-clouds to get the most recent info.

So what Anastasia says is correct - it's the concern of the Juju release process and it not something that we expose to the user.

[Nam Nguyen (nammn)]

Maybe mitechie or hml can give more input how they see it, as they gave the input about opening this to discuss this further.

IMO I would not label this as a but, more like things we should take into consideration to maybe document. As it seems that people can get confused.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.