improvement when installing JMS via mascli when installing manage

[GuilhermeFAC]

@andrercm Good afternoon, see the possibility of improvement by selecting the option to install jms server when installing manage.

1 - Make the jms go up by enabling the cqin and cqout queues by default (cqout only available in 8.11) following document: https://www.ibm.com/support/pages/node/6962441

2 - Today, when choosing to install jms using mascli, maange goes up with separate report, ui, integration bundles, see the possibility of adding an option to upload jms + pod "all" only.

[andrercm]

Hi @GuilhermeFAC so these two features should be also available already in ansible-devops... when calling suite_app_config while installing Manage, you can provide the following parameters:

export MAS_APP_SETTINGS_SERVER_BUNDLES_SIZE="snojms" # This server bundle flavor deploys only all + jms pods
export MAS_APP_SETTINGS_DEFAULT_JMS="true" # This should enable both cqin and cqout queues. By default it is set to `false`

If you want to have a preview test, you can install MAS/Manage using this cli version 7.18.0-pre.manage-additional-settings

As in:

docker run -v $HOME:/tmp -ti --rm --pull always quay.io/ibmmas/cli:7.18.0-pre.manage-additional-settings

Any feedbacks are welcome!

[andrercm]

Here's how it should look like with 7.18.0-pre.manage-additional-settings

[GuilhermeFAC]

Very good @andrercm , exactly the way I imagined, it makes it a lot easier. If you test it, I'll give you feedback.

[GuilhermeFAC]

Hi @andrercm

and the ingress is ok in the cluster

[andrercm]

@GuilhermeFAC is this an IBM Cloud cluster?

[GuilhermeFAC]

Yes @andrercm

[andrercm]

interesting... in my IBM Cloud env, this issue does not happen... can you pull the cli image again? I added some debugs in this task to understand what's happening:

docker run -v $HOME:/tmp -ti --rm --pull always quay.io/ibmmas/cli:7.18.0-pre.manage-additional-settings

If you can provide me the debug logs from the next time you execute that would help assess the issue.

[GuilhermeFAC]

What logs? I rerun Docker and return the same error itconsol-install-j7l7n-pre-install-check-pod-step-ocp-verify.log

[andrercm]

From your logs it does not seems you're running the latest 7.18.0-pre.manage-additional-settings version... i added some debug to that... can you go to your openshift and find namespace mas-$MAS_INSTANCE_ID-pipelines and then Workload > Deployments > mas-cli > YAML tab and set imagePullPolicy: Always then save... It should force the 7.18.0-pre.manage-additional-settings image to be pulled as a new image then hopefully it will pick the latest... then rerun the pipeline again.

[GuilhermeFAC]

I did that and now it's gone and there's no error hahaha... I don't know what happened.

[andrercm]

ok... so i added a potential fix to that in a hope that it fixes it... so cool it did fix it :)

[GuilhermeFAC]

Finally, I see if the installation occurred as defined in the parameters

[andrercm]

can you go to Parameters tab and see if you can find some parameters values for the following:

• mas_app_settings_base_lang
• mas_app_settings_secondary_langs
• mas_app_settings_server_bundle_size
• mas_app_setting_default_jms
• mas_app_setting_server_timezone
• db2_type
• db2_timezone

[GuilhermeFAC]

@andrercm about the timezone in the db2u pod, he defined the property but the server continues with UTC time:

For the server to stay in the chosen zone, it is necessary to add a variable in StatefulSets -> db2u -> Environment

TZ -

This will create a new pod of the db2u instance and the server will have the timezone applied correctly.

[andrercm]

Oh... so the timezone property in the DB2UCluster server for nothing?

[GuilhermeFAC]

I believe that in addition to the property in Db2cluster there must also be this "TZ", but I can't say if only the TZ would solve it, because if you look at the jvm pod or the maxinst pod there is also this TZ in the environment, when We define the timezone through the manage workspace and it adds it to maxinst. I believe there is something missing when we define it in Db2ucluster that should also add this TZ.

Fallow link : https://www.datagenx.net/2020/03/set-timezone-for-containers-in-openshift.html#:~:text=There%20is%20a%20very%20simple,containers%20to%20the%20timezone%20specified.&text=As%20soon%20as%20this%20command,with%20the%20new%20environment%20variable.

[GuilhermeFAC]

Just to update, I installed the maximum with db2oltp database, jms (continuous queue enabled) + pod all, added base language EN + PR-BR and the manage Brazil/East timezone. It went up without any problems and with everything configured. Very good thank you.

This is the only detail left from TZ to db2 in environment

[andrercm]

So it seems setting the advsOpt.timezone is really the only thing needed to set it during DB2 instantiation... https://www.ibm.com/docs/en/cloud-paks/cp-data/4.8.x?topic=administering-setting-timezone-new-existing-deployments

Can you test the two approaches described in this doc and let me know if any works for you? Ideally we would need to have an option that could be set in both ManageWorkspace and DB2 using the same parameter value. i.e both db2_timezone and mas_app_settings_server_timezone set to the same value to simplify the process.

[GuilhermeFAC]

So @andrercm , I followed this IBM document when I did the manual, but what I told you happened, even though there in the log it shows that the timezone is defined and even restarting the db2u pod it does not change the server's timezone, I have already suggested that IBM correct it this document because it only worked when I added this TZ variable to the environment. So both can be managed with db2, but you need to add this TZ variable to db2u to actually change the timezone on the server, in that pod.

[andrercm]

Does it work if i set TZ=GMT (using timezone code instead of city) for example? Asking this since ManageWorkspace timezone uses timezone code so we could use same value for both..

[GuilhermeFAC]

In TZ if you enter a valid value it works, In Mascli I defined Brazil/East.

The same timezone values in ManageWorkspace can be used to define the db2u TZ. For example, the list has Brazil/East, America/Sao Paulo, so whatever is defined in ManageWorkspace can also be defined in the TZ of the db2u pod.

[andrercm]

That's good... ok, so there seems to need an extra step to set the db2 statefulset with this env var... i'll do some research to see if there's another way to set it upfront in the db2ucluster, it would be better idea than waiting for db2 to be created then setting the var afterwards. If there's a way to set this while the db2 is being created that would safe lot of time.

[GuilhermeFAC]

A tip is to see how it is done for Manage, as it has already defined this 'TZ' variable in the environment in the JVM pods and in maxinst when we choose a timezone in the manageworkspace

[wangqymro]

@andrercm the tz on the Manageworkspace CR only controls the timezone of the application server, not the database's timezone as database creation and maintenance is not part of Manage operator's responsibility at this point. The cli/ansible will need to populate db2ucluter's timezone when taking the same timezone in manage installation. Also, the db2u timezone functionality only works after the one coming with CPD 4.7.3, or 11.5.8.0-cn5.

[andrercm]

Thanks for clarifying this @wangqymro ... in our case, mas cli does not use DB2 on top of CPD... it uses DB2 standalone currently at s11.5.9.0-cn1 version.

[andrercm]

@GuilhermeFAC

Coming back to this, I have made changes that sets the TZ variable in DB2 statefulset as described here

So db2u pod now can be set:

The changes are included in this cli version 8.1.0-pre.manage-additional-settings

Can you check if this version contains everything you are expecting? I'll be waiting your feedback to promote these changes.

[GuilhermeFAC]

Ok @andrercm , I'll do a new installation to test this change!

[andrercm]

@GuilhermeFAC thanks! let me know how that goes and if any adjustments are needed.

[GuilhermeFAC]

@andrercm Good afternoon, I instaled using 8.1.0-pre.manage-additional-settings but the varible TZ was not placed in the db2 statefulset

[andrercm]

@GuilhermeFAC can you provide me logs from the db2 task? Also make sure you're running the latest version of 8.1.0-pre.manage-additional-settings

Can you go to your openshift and find namespace mas-$MAS_INSTANCE_ID-pipelines and then Workload > Deployments > mas-cli > YAML tab and set imagePullPolicy: Always then save... It should force the 8.1.0-pre.manage-additional-settings image to be pulled as a new image then hopefully it will pick the latest... then rerun the pipeline again.

[GuilhermeFAC]

install-egv6q7-db2-manage-pod-step-db2.log

Allrigth , I am going to try

[andrercm]

@GuilhermeFAC i found the problem... the code was not finding the right db2 pod to add the timezone var... it was finding the db2-etcd pod...

TASK [ibm.mas_devops.db2 : Set timezone variable in db2u statefulset] **********
changed: [localhost] => changed=true 
  cmd: oc set env sts c-mas-cp4upgrade-main-manage-etcd TZ=UTC -n db2u
  delta: '0:00:00.388820'
  end: '2024-04-12 21:47:56.030679'
  msg: ''
  rc: 0
  start: '2024-04-12 21:47:55.641859'
  stderr: ''
  stderr_lines: <omitted>
  stdout: statefulset.apps/c-mas-cp4upgrade-main-manage-etcd updated
  stdout_lines: <omitted>

TASK [ibm.mas_devops.db2 : debug] **********************************************
ok: [localhost] => 
  db2_set_timezone_output.stdout_lines:
  - statefulset.apps/c-mas-cp4upgrade-main-manage-etcd updated

TASK [ibm.mas_devops.db2 : debug] **********************************************

I fixed the problem, it should be available now in 8.1.0-pre.manage-additional-settings

[GuilhermeFAC]

Hi @andrercm .

I did the procedure you asked me to do and rerun the pipeline and now it has defined the TZ variable in the statefullset.

[andrercm]

Great news @GuilhermeFAC ... is there any other feedback you want to highlight? Or are all the implementations you expected contained at this point?

[GuilhermeFAC]

At the moment the most necessary ones are implemented, it looks very good, Thank you.

I have a suggestion but it is for the storage issue, being able to select the type of storage per project, for example, in db2 select file and block gold(10 iops), for prometheus select bronze(2 iops), pvc for doclinks bronze(2iops) ), being able to choose a project that uses separate PVC, as not everything needs 10 Iops. but this point must be more complicated for you. But if possible it would be cool.

[andrercm]

Those are good feedbacks @GuilhermeFAC

I think some of that might be accomplished currently using the ansible-devops collection directly, but they might but be backported/supported in MAS cli yet. In MAS CLI, the current approach is to defined one specific type for file and another type for block storage and reuse that across the install pipeline where needed.

Feel free to open an issue for this customization in the CLI repo to a future enhancement: https://github.com/ibm-mas/cli

As to the scope of improvements that we have worked together, I'll close the current issue as everything has been validated on your side! Thanks a lot for your help, hopefully pretty soon these changes will be merged and released in the MAS CLI. In meanwhile you can keep using the beta version provided.