Specific machine placement by hostname in bundle

Bug #1882025 reported by Vern Hart
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Wishlist
Unassigned

Bug Description

From the command line we can specify:

    juju deploy graylog --to graylog-1.maas

But there isn't an equivalent for bundles.

We commonly tag individual machines with their name and use those tags as a constraint in the machines section and use the machine id in an application's "to:" directive:

    machines:
      "0":
        constraints: tags=graylog
    applications:
      graylog:
        charm: cs:graylog
        to:
        - "0"

It could potentially simplify and make things a bit clearer if we could specify the machine name directly in the to directive:

    applications:
      graylog:
      charm: cs:graylog
      to:
      - "graylog-1.maas"

Is this technically feasible?

Tags: bundles
Revision history for this message
Ian Booth (wallyworld) wrote :

It is feasible but some work is needed since in bundles, the "to" is interpreted as follows:

(<containertype>:)?(<unit>|<machine>|new)

So we'd need to figure out a syntax to use to support the new semantics.

Changed in juju:
milestone: none → 2.9-beta1
status: New → Triaged
Revision history for this message
Vern Hart (vern) wrote :

containertype is [none|kvm|lxd] (or lxc which gets interpreted as lxd)
unit is <application>/<unitid>
application is [-a-z0-9]+ (except no double dashes "--" or groups of only numbers)
unitid and machine are both [0-9]+
new is just "new"

Currently it's not valid to have a period (.) in the bundle's "to" directive.

So it seems to me that a check to see if it has a period would be sufficient to try the string as a hostname or IP address.

Now that I have found the resolveMachine function in cmd/juju/application/bundle.go I see that it's not quite that simple. But it does seem possible.

Changed in juju:
milestone: 2.9-beta1 → 2.9-rc1
Revision history for this message
John A Meinel (jameinel) wrote :

If we implement support for this, we should qualify it with a prefix (like zone=, or subnet=, we could support hostname= or name=)
I don't want to have a heuristic of whether or not a '.' is present to treat the content differently.

Revision history for this message
Ian Booth (wallyworld) wrote :

The scope of the change to support extending the bundle placement syntax to allow compatibility with the single charm deployment placement syntax is non-trivial. Not only does the bundle parsing code need to be changed and new semantics wired through, so too does the bundle diff handling which compares a bundle with what's been deployed already to generate a set of changes.

Moving to 2.9.1 milestone given it is unlikely to be able to be done prior to 2.9.0

Changed in juju:
milestone: 2.9-rc1 → 2.9.1
Ian Booth (wallyworld)
Changed in juju:
milestone: 2.9.1 → 2.9.2
Changed in juju:
milestone: 2.9.2 → 2.9.3
Changed in juju:
milestone: 2.9.3 → 2.9.4
Changed in juju:
milestone: 2.9.4 → 2.9.5
Changed in juju:
milestone: 2.9.5 → 2.9.6
Changed in juju:
milestone: 2.9.6 → 2.9.7
Changed in juju:
milestone: 2.9.7 → 2.9.8
Changed in juju:
milestone: 2.9.8 → 2.9.9
Changed in juju:
milestone: 2.9.9 → 2.9.10
Changed in juju:
milestone: 2.9.10 → 2.9.11
Changed in juju:
milestone: 2.9.11 → 2.9.12
Changed in juju:
milestone: 2.9.12 → 2.9.13
Changed in juju:
milestone: 2.9.13 → 2.9.14
Changed in juju:
milestone: 2.9.14 → 2.9.15
Changed in juju:
milestone: 2.9.15 → 2.9.16
Changed in juju:
milestone: 2.9.16 → 2.9.17
Changed in juju:
milestone: 2.9.17 → 2.9.18
Changed in juju:
milestone: 2.9.18 → 2.9.19
Changed in juju:
milestone: 2.9.19 → 2.9.20
Changed in juju:
milestone: 2.9.20 → 2.9.21
Changed in juju:
milestone: 2.9.21 → 2.9.22
Changed in juju:
milestone: 2.9.22 → 2.9.23
Changed in juju:
milestone: 2.9.23 → 2.9.24
Changed in juju:
milestone: 2.9.24 → 2.9.25
Changed in juju:
milestone: 2.9.25 → 2.9.26
Changed in juju:
milestone: 2.9.26 → 2.9.27
Changed in juju:
milestone: 2.9.27 → 2.9.28
Changed in juju:
milestone: 2.9.28 → 2.9.29
John A Meinel (jameinel)
Changed in juju:
milestone: 2.9.29 → none
tags: added: bundles
Revision history for this message
Vern Hart (vern) wrote :

It occurs to me that this might be done with constraints.

I have not tested using tags in application constraints but if that works, it would accomplish the idea of simplifying the bundle.

Even better would be to implement a hostname constraint that would have a similar effect.

While this wouldn’t fulfill the exact original request, it seems like it’d be more in line with how juju currently works.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.