Juju.offer and Juju.consume, temp_model unintuitive design

[yanksyoon]

Hello!

I was wondering the rationale behind some of the design decisions in the library which isn't quite documented.

Firstly, the temp_model and the controller argument

It is easy to use the Juju fixture like so:

@pytest_asyncio.fixture(scope="module", name="juju")
def juju_fixture(request: pytest.FixtureRequest) -> Generator[jubilant.Juju, None, None]:
    """The machine model for machine charms."""
    with jubilant.temp_model(controller=LXD_CONTROLLER_NAME) as juju:
        yield juju

@pytest_asyncio.fixture(scope="module", name="k8s_juju")
def k8s_juju_fixture(request: pytest.FixtureRequest) -> Generator[jubilant.Juju, None, None]:
    """The model for K8s charms."""
    with jubilant.temp_model(controller=MICROK8S_CONTROLLER_NAME) as juju:
        yield juju

Here, we see that the temp_model takes in the argument controller. Since doing so, I have assumed that the controller information would be persisted. However, that is not the case. Using k8s_juju to create offers when the current controller is on the lxd makes the k8s_juju work on the LXD Juju.

Secondly, the prefixed controller name in model attribute.

When accessing the juju.model the syntax output is <controller>:<model> when the model is in another controller. I would expect the juju class to have a separate controller attribute rather than prefixing the .model attribute with the controller name. Due to this behavior, whenever I need do juju.consume, I would need to take the model, separate it at : and use controller and model name separately.

Lastly, the use of -m or -c to set model/controller rather than the environment variables (JUJU_MODEL JUJU_CONTROLLER)

On production bastion hosts, the Juju models and controllers are switched using JUJU_MODEL and JUJU_CONTROLLER environment variables. This would allow the jubilant.temp_model to work in according controllers that were set during the creation. What is the rationale behind explicitly using -m or -c over the environment variables?

Jubilant has been quite helpful, thank you for addressing my concerns!

[dimaqq]

Hi @yanksyoon, can you elaborate a bit how you'd use Jubilant in production?

[yanksyoon]

@dimaqq - we don't use jubilant in production, the comment was rather about how Juju is setup in bastion hosts. Rather than using -c or -m flags, the JUJU_* environment variables are configured to facilitate switching of controllers/models.

[benhoyt]

However, that is not the case. Using k8s_juju to create offers when the current controller is on the lxd makes the k8s_juju work on the LXD Juju.

This is strange to me. Using temp_model (as your fixtures do) with a controller argument will call add_model with that controller, and add_model will set self.model to f'{controller}:{model} in that case, so that subsequent Juju methods operate on that controller and model. Is this not happening?

Secondly, the prefixed controller name in model attribute.

This is somewhat based on design decisions, and somewhat backwards compatibility.

However, we could consider adding a Juju.controller : str | None property that fetched the controller name out of the first part of .model if it has a : in it, otherwise gives None. This might help a little to use with something like Juju.consume.

Juju.consume is a bit funny, because its controller argument refers to the remote end's controller. There are potentially two controllers at play...

What is the rationale behind explicitly using -m or -c over the environment variables?

I'd much prefer Jubilant itself, as a library, doesn't look at environment variables, but explicitly uses arguments for these things. However, you'd be welcome to make your own fixtures that use environment variables.

What I think we should do now:

• Add a Juju.controller property as mentioned above.

@tonyandrewmeyer Interested in your take here too, as you worked on the existing controller support.

[yanksyoon]

This is strange to me. Using temp_model (as your fixtures do) with a controller argument will call add_model with that controller, and add_model will set self.model to f'{controller}:{model} in that case, so that subsequent Juju methods operate on that controller and model. Is this not happening?

I have had to add a controller argument to the k8s_juju offer fixture to correctly create an offer. Otherwise it would error out with ERROR model name "microk8s:jubilant-934f1288" not valid due to the prefixed controller name.

In order to get around this, I then had to split the juju.model (juju.model.split(":")[1]) to get the actual model name to create an offer.

[tonyandrewmeyer]

Secondly, the prefixed controller name in model attribute.

This is somewhat based on design decisions, and somewhat backwards compatibility.

Yeah, there was some discussion at the time we added support for multiple controllers about whether controller should be separate from model.

It might have been better to have .model and .controller and then have --include-model combine the two, but I don't see how we can change that in v1.

Due to this behavior, whenever I need do juju.consume, I would need to take the model, separate it at : and use controller and model name separately.

However, we could consider adding a Juju.controller : str | None property that fetched the controller name out of the first part of .model if it has a : in it, otherwise gives None. This might help a little to use with something like Juju.consume.

It doesn't seem like this would be particularly useful outside of consume/offer. I suppose you could juju.add_model("model2", controller=juju.controller) and also use it with add_credential.

It seems like there are two reasonable alternatives now:

• Have a CONTROLLER name defined in the code somewhere (or maybe this is a fixture if it's being generated on the fly) that you refer to whenever you need it.
• Get the name from the status (controller = juju.status().model.controller). This is more expensive, but perhaps not so much that it's an issue, particularly for tests? It's also very cacheable.

So I'm not completely opposed to a .controller property, and I think there's a reasonable chance that in a v2 that might exist, but I'm also not convinced that there's much need for it.

[tonyandrewmeyer]

I have had to add a controller argument to the k8s_juju offer fixture to correctly create an offer. Otherwise it would error out with ERROR model name "microk8s:jubilant-934f1288" not valid due to the prefixed controller name.

If I understand correctly, what you'd want here is for Jubilant to treat controller=None in offer() as "current controller" means the controller set in the Juju object, rather than the controller the Juju CLI has active.

This is a bit of an oddity in Jubilant. For the most part, we don't use the Juju CLI state, but the controller is an exception, either broadly if you don't explicitly set it (so it's not in .model) or specifically for add_model, consume, offer, add_credential. I think we would want to redesign this in a v2, but I don't see how it can change in v1.