| wallyworld | _thumper_: one for the road if you have a moment https://github.com/juju/juju/pull/11885 | 01:03 |
|---|---|---|
| === _thumper_ is now known as thumper | ||
| * thumper looks | 01:48 | |
| sou | Hey good people, I am trying to understand different ways of scaling an openstack compute cluster. I know that we can scale a compute cluster by adding number of units. For example using the below command will add | 06:53 |
| sou | 2 compute units: juju add-unit -n2 nova-compute | 06:54 |
| sou | But I was wondering if there is any way I can scale the cluster by just running : juju deploy habundle.yml | 06:54 |
| sou | habundle.yml has details about 3 machines with constraint "tag=compute" | 06:55 |
| sou | machines: '0': series: bionic constraints: tags=controller '1': series: bionic constraints: tags=controller '2': series: bionic constraints: tags=controller '3': series: bionic constraints: tags=compute '4': series: bionic constraints: tags=compute '5': series: bionic constraints: tags=compute | 06:55 |
| sou | Without modifying habundle.yml, is it possible to scale? | 06:56 |
| sou | I want to add 4th compute machine | 06:56 |
| sou | My nova-compute application looks like this | 06:57 |
| sou | nova-compute: charm: cs:nova-compute-302 num_units: 3 options: cpu-mode: custom cpu-model: kvm64 config-flags: default_ephemeral_format=ext4,instance_name_template=%(hostname)s enable-live-migration: true enable-resize: true migration-auth-type: ssh virt-type: kvm encrypt: true | 06:58 |
| sou | ephemeral-device: /dev/bcache2 openstack-origin: cloud:bionic-stein flat-interface: eno6 libvirt-image-backend: raw resume-guests-state-on-host-boot: True worker-multiplier: 0.015 to: - '3' - '4' - '5' | 06:58 |
| sou | Appreciate any tips | 06:58 |
| wallyworld | sou: the scale is defined in the bundle yaml as num_units, so you need to change that to 4 if you want to reapply the bundle to scale up | 06:59 |
| sou | Thanks a lot wallyworld. This would mean each time I want to scale the cluster I will have to update ha_bundle.yml. Do you think by using constraints here would work. For example: | 07:02 |
| sou | nova-compute: charm: cs:nova-compute-302 num_units: 3,new constraints: tag=compute ... | 07:02 |
| sou | I am trying to understand if I can achieve scaling by having a generic bundle.yml, which would take care of any new machines with tag=compute | 07:03 |
| wallyworld | constraints are used to help define on what node a unit should be placed when a unit needs to be deployed somewhere, rather than the concept of "fill all machines that have this tag with a unit". juju provides the add-unit primitive to enable workloads to be scaled up or down. but it doesn't do things automatically like you are wanting to do. the idea is that folks that need bespoke scaling behaviour can write scripts to do it | 07:07 |
| wallyworld | using the juju primitives | 07:07 |
| sou | Perfect. Thanks wallyworld for the insight!! | 07:08 |
| wallyworld | no problem | 07:08 |
| stickupkid | manadart_, achilleasa https://github.com/juju/charm/pull/312 | 09:49 |
| stickupkid | One thing I really need to work out, if I do update all the charm urls, then uniters will notice a change I'm guess and force a charm update | 09:50 |
| stickupkid | *guessing | 09:50 |
| achilleasa | can I get a review on https://github.com/juju/juju/pull/11887? | 11:40 |
| achilleasa | stickupkid: can you take a look at https://github.com/juju/juju/pull/11889? | 14:13 |
| stickupkid | achilleasa, done | 14:16 |
| achilleasa | hml: can you take a look at this small PR? https://github.com/juju/juju/pull/11890 | 14:44 |
| hml | achilleasa: sure, will start in 30 or so | 14:45 |
| stickupkid | hml, also CR for this one https://github.com/juju/juju/pull/11888 | 14:50 |
| hml | stickupkid: adding to the queue. ;-) | 14:52 |
| hml | stickupkid: you have a compile fail on the test run | 15:23 |
| achilleasa | stickupkid: looks like that echo -e was needed... it doesn't expand line-feeds otherwise ;-( | 15:27 |
| achilleasa | I will put it in the develop path and in my removejujuservices one that is pending review for 2.8 | 15:28 |
| hml | achilleasa: one suggestion and a tic | 15:29 |
| achilleasa | hml: nice catch | 15:30 |
| achilleasa | hml: updated the PR; looks OK now? (I added one extra commit for adding a -e to the test-runner changes that I missed in my other PR) | 15:38 |
| hml | achilleasa: approved | 15:39 |
| stickupkid | hml, nice, we don't need a charm URL upgrade step for https/http v2 charm URLs, it's impossible to get the old version in state even if it's written to mongo somehow | 15:47 |
| hml | stickupkid: ha | 15:48 |
| === manj-gnome is now known as jj8009 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!