Machine constraints are used as Controller constraints

actually it is the other way around. --constraints affects everything,
including the controller and any future applications that are deployed.
--bootstrap-constraints only effects the controllers and not deployed apps.

John
=:->

On Tue, May 1, 2018, 19:35 Peter Matulis <email address hidden>
wrote:

> Public bug reported:
>
> When I specify a default constraint during controller-creation time with
> '--constraints' it appears that it (here disk space) gets applied to the
> controller:
>
> $ juju bootstrap --no-gui --bootstrap-series=bionic --constraints
> "root-disk=64G" aws aws-bionic-constraints2
> $ juju ssh -m controller 0 'df -h'
>
> /dev/xvda1 62G 3.0G 60G 5% /
>
> When I use no constraints I get a much smaller disk for the controller:
>
> $ juju bootstrap --no-gui --bootstrap-series=bionic aws
> aws-bionic-constraints3
> $ juju ssh -m controller 0 'df -h'
>
> Filesystem Size Used Avail Use% Mounted on
> udev 1.9G 0 1.9G 0% /dev
> tmpfs 376M 744K 375M 1% /run
> /dev/xvda1 31G 3.0G 28G 10% /
>
> I thought the controller is only affected by '--bootstrap-constraints'?
>
> https://paste.ubuntu.com/p/BCcqHtGWfr/
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
>
> ** Tags: docteam
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1768308
>
> Title:
> Machine constraints are used as Controller constraints
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1768308/+subscriptions
>

Thanks. I will open a bug for fixing the help. Currently it shows:

If '--constraints' is used, its values will be set as the default
constraints for all future workload machines in the model, exactly as if
the constraints were set with `juju set-model-constraints`.

Having two options that affect the same object is counterintuitive, especially since the help does not mention the aspect of precedence (i.e. '--bootstrap-constraints' overrides '--constraints').

Do the individual constraints override the other or do all the constraints given by --bootstrap-constraints get preferred?

@Peter Matulis (petermatulis),

This is an interesting question :) From pure speculation and intuitively, I would have expected us to have implemented --bootstrap-constraints taking precedence over --constraints if there are conflicting values.
It is also possible that while attempting to merge the 2 definitions together for bootstrapping instance, we'd discover the conflict and will stop bootstrap generating a helpful message to the user :)

We should double-check this scenario when we come to re-defining the help text. Thank you for such an interesting thought!!

Just a follow up, the code to determine constraints for bootstrap is in the code starting from https://github.com/juju/juju/blob/develop/environs/bootstrap/bootstrap.go#L259

I have not done full investigation yet.

IMO, --constraints should be deprecated. All it does more than --bootstrap-constraints is add constraints to the 'default' model.

Actually, let me correct that.

--constraints affects every machine (controller and non-controller) in either the 'controller' or 'default' models. So what it does more than --bootstrap-constraints is:

a) Adds constraints for machines in the 'default' model
b) Adds constraints for non-controller machines in the 'controller' model

This is correct.

The intent is that --bootstrap-constraints is specified for controller machines and overrides --constraints. ---constraints themselves are specified for all other machines regardless of the model. However, I think that constraints are also model specific and, thus, individual models can have their own copy.

I put a lot of thought into my suggested wording in bug 1784675 which was marked as a duplicate of this bug (which I find dubious btw). I don't want to lose that. Here it is:

--------------------------

The pertinent help in `bootstrap` for constraints is:

===

--bootstrap-constraints (= "")
    Specify bootstrap machine constraints

--constraints (= "")
    Set model constraints

If '--bootstrap-constraints' is used, its values will also apply to any
future controllers provisioned for high availability (HA).

If '--constraints' is used, its values will be set as the default
constraints for all future workload machines in the model, exactly as if
the constraints were set with `juju set-model-constraints`.

===

I'd like to suggest the following wording:

===

--bootstrap-constraints (= "")
    Set constraints for controller machines

--constraints (= "")
    Set constraints for the 'controller' and 'default' models

If '--bootstrap-constraints' is used, its values will be used as constraints
for controllers only, including any future ones provisioned for high
availability.

If '--constraints' is used, its values will be used as constraints for every
machine in the 'controller' and 'default' models. This includes controllers
as well as non-controllers.

===

@Peter Matulis (petermatulis),

Existing wording is correct, see my comment #7 here.

Suggested wording is misleading as for (1) we do want to explicitly differentiate between controller machines and model machine; (2) --constraints apply to any model machine not just the ones in the models you named.

Feel free to reach out on IRC if there is a nuance in your wording that I am missing that is not covered by our original wording.

Well I guess there's a bug then. I, of course, tested all this before spending time with this. The constraints do *not* apply to new models.

Just wanted to confirm Peter's point that `juju bootstrap --constraints` only seems to affect the 'controller' and 'default' model. Those constraints were not applied to any other models I created.

Steps on LXD cloud:
* juju bootstrap lxd --constraints mem=768M
* juju deploy ubuntu
* juju add-model test
* juju deploy ubuntu
* lxc config get <instance-id-juju-controller> limits.memory
* lxc config get <instance-id-default-model-ubuntu> limits.memory
* lxc config get <instance-id-test-model-ubuntu> limits.memory # missing memory limit constraint

Ok, I can see where the confusion arises..

Bootstrap is the only command that calls model-constraints 'constraints'.

In other words, you specify model constraints at bootstrap using --constraints options. After bootstrap, these constraints are known and are manipulated as --model-constraints (see help for either get- or set-model-constraints).

I think cleaner solution is to rename this option to be "--model-constraints" as this is what we are really talking about at bootstrap.

Please note that everywhere else in "juju" 'constraints' mean 'application constraints'.

I had to read your comment a few times but I still don't see how it explains what Sandor and I have observed: that `bootstrap --constraints` only applies to the 'controller' and 'default' models.

I've never heard the term "application constraint" but what I think you mean is that it's a constraint that is not inherited from a model. The `add-machine` command does not fit in to this definition.

In lieu of getting rid of `bootstrap --constraints` entirely I agree that renaming the option is an improvement. The problem with `--model-constraints` is that it suggests that it applies to a specific model, or even that it applies to every model (present and future), which it does not.

Let's talk offline.

1. (TO-DO)
I have verified that indeed the constraints specified at bootstrap time only stored for the initial two models. It was not an intent and we will rectify. The behavior will be analogous to --config which when specified at bootstrap is treated as default/initial for all models added to the controller. Consequently, model constriants specified at bootstrap will be treated as default model constraints for all models added to this controller.

2. (TO-DO)
This also highlights the need to have --constraints as an option to 'add-model' to provide users with the ability to change/specify these at the model creation time rather avoiding our current 2-step process of 'add-model' and then 'set-model-constraints'. This will also be analogous to the model config behavior.

3. (TO-DO)
All instances of model-constraints options being called 'constraints' will be addressed to avoid further confusion with application constraints. Essentially, it will mean that commands such as bootstrap will gain a new option of 'model-constraints' and current 'constraints' option will have a deprecation warning and a suggestion to use 'model-constraints' instead.

4.
I have verified that there is no conflict between bootstrap-constraints and constraints. In other words, when both are specified as per example below, bootstrap-constraints ONLY applies to controller machines whereas constraints ONLY applies to non-controller (i.e. model) machines. Since the 2 are never merged, there is no need to worry about one overwriting the other. bootstrap-constraints will take precedence over constraints for controller machines when provided. The scenario I've used:
    i. bootstrap with ' --bootstrap-constraints root-disk=32G --constraints root-disk=64G';
    ii. switch to controller model;
    iii. check controller machine contains as a hardware characteristics root-disk of at least 32G, and it does https://pastebin.ubuntu.com/p/p7G2hRKvRT/ ;
    iv. deploy an application;
    v. check unit machine contains as a hardware characteristics root-disk of at least 64G, and it does https://pastebin.ubuntu.com/p/bZDcgy5WV3/.

Thank you for working through this muddle and bringing it to our attention.

Nicely done.

Comments:

1. I believe `bootstrap --config` affects just the 'controller' and 'default' models while `--model-default` affects all models, including any future ones. Perhaps `--model-default` should be renamed `--model-defaults`.

2. Agreed.

3. I would avoid the term "application constraints". I'm still unsure of what you mean by it. When you do `add-machine --constraints` are these application constraints?

4. The documentation will need to be altered. I went with the earlier statement that individual `--bootstrap-constraints` override corresponding values from `--constraints`. From what I understand now, when used in combination, each "batch" of constraints is fenced off from the other. This is clearer.

I just remembered that I once got an error when using `--model-default` and I had to use `--config` instead. The error said that the key wasn't applicable. So I don't think these two can be used interchangeably. Testing needed.

I'd like to challenge the need for model-constraints. The constraints stored in the model are just the values that will be used when applications are brought in without anything specified on their own. It's the same set of values, just if it's the default values the model thinks about.

I see nothing wrong with

juju add-model rickstuff --constraints mem=8G

It's just creating a model with the default constraints value set to 8G of ram.

I do agree that on bootstrap --constraints should be set for all models by default. At this point it's a control default option inherited by models on that controller shouldn't it be?

I do think that --bootstrap constraints should be its own entity as you're speaking about the actual controllers and not tied to default workloads of any sorts.

@Richard Harding (rharding),

The proposal to rename --constraints to --model-constraitns is for clarity. After bootstrap, these constraints on the model are manipulated by set-model-constraints and get-model-constraints command. The problem at the moment is the consistent terminology.

Note that these commands are not new and have existed in Juju for a while.

@Peter Matulis (petermatulis) ,

I am surprise to hear that application constraints as a concept is news to you. How do you look up constraints now? Both set-constraints and get-constraints commands in Juju take an application as a mandatory argument.

@Anastasia

Yes, some commands take an application name as an argument. Now consider specifying a constraint with `add-machine`. Is it an application constraint? If not, then what is it? If one later deploys an application upon that machine does the constraint become an application constraint? So coining terms can be limiting. The online docs talk in terms of hierarchical scopes (all-models, model, application, application-unit, and machine) with each scope possibly inheriting constraints from the level above.

@Peter Matulis (petermatulis),

At the end of the day, a constraint can only be a machine constraint - it is specifying a hardware characteristic.

However, a constraint can be specified at different stages of system deployment. In Juju, you can specify a constraint when:

  a. you add a machine, see 'juju help add-machine'. This is an instruction for this one machine.;
  b. you deploy an application, see 'juju help deploy'. This is an instruction for all unit machines for this application.;
  c. you bootstrap a controller, see 'juju help bootstrap'. This is an instruction for all machines in this model. This is the bit that needs some love as per comment # 14. We need to have the ability to propagate it to all models within the controller as well as have the ability to override it at 'add-model'.

As you can see, these correspond directly to 'hierarchical scopes' you describe above. So I am trying to figure out where is the confusion...

I also feel like the bug report is not the right place to clarify an understanding of a concept. I am happy to have a discussion outside of the bug tracker with the view to have this added to online documentation.

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.